Laser scanner with real-time, online ego-motion estimation

ABSTRACT

A method comprises accessing a data set comprising a LIDAR acquired point cloud comprising a plurality of points each of which are attributed with at least a geospatial coordinate, sub-sampling at least a portion of the plurality of points to derive a representative sample of the plurality of points and displaying the representative sample of the plurality of points.

STATEMENT OF PRIORITY

This application is a bypass continuation of International ApplicationPCT/US2017/055938 entitled “LASER SCANNER WITH REAL-TIME, ONLINEEGO-MOTION ESTIMATION,” filed Oct. 10, 2017 (KRTA-0008-WO) which claimspriority to, and is a continuation-in-part of, PCT Application No.PCT/US2017/021120 entitled “LASER SCANNER WITH REAL-TIME, ONLINEEGO-MOTION ESTIMATION,” filed on Mar. 7, 2017 (KRTA-0005-WO).PCT/US2017/055938 (KRTA-0008-WO) further claims priority to U.S.Provisional No. 62/406,910, entitled “LASER SCANNER WITH REAL-TIME,ONLINE EGO-MOTION ESTIMATION,” filed on Oct. 11, 2016 (KRTA-0002-P02).This application is also a continuation-in-part of U.S. Nonprovisionalpatent application Ser. No. 16/125,054 entitled “LASER SCANNER WITHREAL-TIME, ONLINE EGO-MOTION ESTIMATION,” filed Sep. 7, 2018(KRTA-0005-U01). U.S. Nonprovisional patent application Ser. No.16/125,054 (KRTA-0005-U01) is a bypass continuation of PCT ApplicationNo. PCT/US2017/021120 (KRTA-0005-WO). PCT Application No.PCT/US2017/021120 (KRTA-0005-WO) further claims priority to U.S.Provisional Ser. No. 62/307,061, entitled “LASER SCANNER WITH REAL-TIME,ONLINE EGO-MOTION ESTIMATION,” filed on Mar. 11, 2016 (KRTA-0001-P01).All of the above-mentioned patent applications are hereby incorporatedby reference in their entirety as if fully set forth herein.

BACKGROUND

An autonomous moving device may require information regarding theterrain in which it operates. Such a device may either rely on apre-defined map presenting the terrain and any obstacle that may befound therein. Alternatively, the device may have the capabilities tomap its terrain while either stationary or in motion comprising acomputer-based mapping system with one or more sensors to providereal-time data. The mobile, computer-based mapping system may estimatechanges in its position over time (an odometer) and/or generate athree-dimensional map representation, such as a point cloud, of athree-dimensional space.

Exemplary mapping systems may include a variety of sensors to providedata from which the map may be built. Some mapping systems may use astereo camera system as one such sensor. These systems benefit from thebaseline between the two cameras as a reference to determine scale ofthe motion estimation. A binocular system is preferred over a monocularsystem, as a monocular system may not be able to resolve the scale ofthe image without receiving data from additional sensors or makingassumptions about the motion of the device. In recent years, RGB-Dcameras have gained popularity in the research community. Such camerasmay provide depth information associated with individual pixels andhence can help determine scale. However, some methods including theRGB-D camera may only use the image areas with coverage of depthinformation, which may result in large image areas being wastedespecially in an open environment where depth can only be sparselyavailable.

In other examples of mapping systems, an IMU may be coupled one or morecameras with, so that scale constraints may be provided from IMUaccelerations. In some examples, a monocular camera may be tightly orloosely coupled to an IMU by means of a Kalman filter. Other mappingsystems may use optimization methods to solve for the motion of themobile system.

Alternative examples of mapping systems may include the use of laserscanners for motion estimation. However, a difficulty of the use of suchdata may arise from the scanning rate of the laser. While the system ismoving, laser points unlike a fixed position laser scanner are impactedby the relative movement of the scanner. Therefore the impact of thismovement may be a factor of the laser points arriving arrive at thesystem at different times. Consequently, when the scanning rate is slowwith respect to the motion of the mapping system, scan distortions maybe present due to external motion of the laser. The motion effect can becompensated by a laser itself but the compensation may require anindependent motion model to provide the required corrections. As oneexample, the motion may be modeled as a constant velocity or as aGaussian process. In some example, an IMU may provide the motion model.Such a method matches spatio-temporal patches formed by laser pointclouds to estimate sensor motion and correct IMU biases in off-linebatch optimization.

Similar problems of motion distortion may be found in the use ofrolling-shutter cameras. Specifically, image pixels may be receivedcontinuously over time, resulting in image distortion caused byextrinsic motion of the camera. In some examples, visual odometrymethods may use an IMU to compensate for the rolling-shutter effectgiven the read-out time of the pixels.

In some examples, GPS/INS techniques may be used to determine theposition of a mobile mapping device. However, high-accuracy GPS/INSsolutions may be impractical when the application is GPS-denied,light-weight, or cost-sensitive. It is recognized that accurate GPSmapping requires line-of-sight communication between the GPS receiverand at least four GPS satellites (although five may be preferred). Insome environments, it may be difficult to receive undistorted signalsfrom four satellites, for example in urban environments that may includeoverpasses and other obstructions.

It may thus be appreciated that there are several technical challengesassociated with merging data from optical devices with other motionmeasuring devices in order to generate a robust map of the terrainsurrounding an autonomous mapping device, especially while the mappingdevice is in motion. Disclosed below are methods and systems of amapping device capable of acquiring optical mapping information andproducing robust maps with reduced distortion.

SUMMARY

The examples in this section are merely representative of some possibleembodiments, but do not reflect all possible embodiments, combination ofelements, or inventions disclosed in this application. In an example, amapping system may include an inertial measurement unit, a camera unit,a laser scanning unit, and a computing system in communication with theinertial measurement unit, the camera unit, and the laser scanning unit.The computing system may be composed of at least one processor, at leastone primary memory unit, and at least one secondary memory unit. Theprimary memory unit may store software that is executed by the at leastone processor, in which the software may include: a first computationalmodule that, when executed by the at least one processor, causes the atleast one processor to compute first measurement predictions based oninertial measurement data from the inertial measurement unit at a firstfrequency; a second computational module that, when executed by the atleast one processor, causes the at least one processor to compute secondmeasurement predictions based on the first measurement predictions andvisual measurement data from the camera unit at a second frequency; anda third computational module that, when executed by the at least oneprocessor, causes the at least one processor to compute thirdmeasurement predictions based on the second measurement predictions andlaser ranging data from the laser scanning unit at a third frequency.

In an example of the mapping system, the first computational module mayfurther include software that, when executed by the at least oneprocessor, causes the at least one processor to correct bias error inthe first measurement predictions based on the second measurementpredictions and the third measurement predictions.

In an example of the mapping system, the first frequency is greater thanthe second frequency and the second frequency is greater than the thirdfrequency.

In an example of the mapping system, the second computational module mayfurther include software that, when executed by the at least oneprocessor, causes the at least one processor to determine whether thevisual measurement data are degraded during a first measurement timeperiod, and upon a determination that the visual measurement data aredegraded during the first measurement time period, compute the secondmeasurement predictions during the first measurement time period equalto first measurement predictions during the first measurement timeperiod.

In an example of the mapping system, the third computational module mayfurther include software that, when executed by the at least oneprocessor, causes the at least one processor to determine whether thelaser ranging data are degraded during a second measurement time period,and upon a determination that the laser ranging data are degraded duringthe second measurement time period, compute the third measurementpredictions during the second measurement time period equal to secondmeasurement predictions during the second measurement time period.

In an example of the mapping system, the primary memory device may storefirst and second sets of voxels in which the first and second sets ofvoxels are based on the third prediction measurements. Each voxel of thefirst set of voxels may correspond to a first volume of space and eachvoxel of the second set of voxels may correspond to a second volume ofspace. The second volume of space may be smaller than the first volumeof space and each voxel of the first set of voxels may be mappable to aplurality of voxels of the second set of voxels.

In an example of the mapping system, the secondary memory unit may storepoint cloud data generated from the third prediction measurements.

In an example, the mapping system may further include a mobile unit, inwhich the inertial measurement unit is on the mobile unit, the cameraunit is on the mobile unit, the laser scanning unit is on the mobileunit, and the computing system is on the mobile unit.

In an example of the mapping system, the mobile unit may include anavigation system for guiding the mobile unit and the navigation systemmay use the third measurement predictions to guide the autonomous mobileunit.

In an example of the mapping system, the third computation module mayuse a scan matching algorithm to compute the third measurementpredictions. The at least one processor may comprise multiple processingthreads. The primary memory device may store software that, whenexecuted by the at least one processor, may manage the processing ofscans of the laser ranging data by the multiple threads such that afirst thread is assigned to scan match a first scan of the laser rangingdata. The first thread may be assigned to scan match a second scan ofthe laser ranging data from a point in time after the first scan, whenthe first thread can process the first scan before arrival of the secondscan. A second thread may be assigned to scan match the second scan ofthe laser ranging data when the first thread cannot process the firstscan before arrival of the second scan.

In an example of the mapping system, the inertial measurement unit,camera unit and laser scanning unit may interface via the computingsystem with an interactive display on which a down-sampled version ofthe scanning data is presented in a three-dimensional representation.

In accordance with an exemplary and non-limiting embodiment, a mappingsystem, comprises an inertial measurement unit, a camera unit, a laserscanning unit, and a computing system in communication with the inertialmeasurement unit, the camera unit, and the laser scanning unit, whereinthe computing system comprises at least one processor, at least oneprimary memory unit, and at least one secondary memory unit, wherein theprimary memory unit stores software that is executed by the at least oneprocessor, wherein the software comprises a first computational modulethat, when executed by the at least one processor, causes the at leastone processor to compute at least one first measurement predictionbased, at least on part, on inertial measurement data from the inertialmeasurement unit at a first frequency, a second computational modulethat, when executed by the at least one processor, causes the at leastone processor to compute at least one second measurement predictionbased, at least on part, on the at least one first measurementprediction and visual measurement data from the camera unit at a secondfrequency and a third computational module that, when executed by the atleast one processor, causes the at least one processor to compute atleast one third measurement prediction based on the at least one secondmeasurement prediction and laser ranging data from the laser scanningunit at a third frequency.

In accordance with an exemplary and non-limiting embodiment, the mappingsystem is comprised of a modularized system structure to address theproblem of bidirectional information flow. Specifically, three modulesaddress the problem step by step from coarse to fine data. Dataprocessing flow may proceed from an IMU prediction module to avisual-inertial odometry module to a scan matching refinement module,while feedback flow occurs in a reverse order to correct the biases ofthe IMU.

In accordance with an exemplary and non-limiting embodiment, the mappingsystem is dynamically reconfigurable. For example, if visual featuresare insufficient for the visual-inertial odometry, the IMU predictionmodule (partially) bypasses the visual-inertial odometry module toregister laser points locally. If, on the other hand, environmentalstructures are insufficient for the scan matching, the visual-inertialodometry output (partially) bypasses the scan matching refinement moduleto register laser points on the map.

In accordance with an exemplary and non-limiting embodiment, the mappingsystem employs priority feedback for IMU bias correction. For example,both the visual-inertial odometry module and the scan matchingrefinement module provide may feedback to the IMU prediction module tocorrect the IMU biases. The feedback may be combined giving priority tothe visual-inertial odometry module. In other words, feedback from thescan matching refinement module compensates for the visual-inertialodometry module in directions where the visual-inertial odometry moduleis degraded.

In accordance with an exemplary and non-limiting embodiment, the mappingsystem employs a two-layer voxel representation of the map. The firstlayer is composed of large voxels. This layer is for map storage. Foreach large voxel that is close to the sensor, the voxel contains asecond layer of small voxels for precisely retrieving the map for scanmatching.

In accordance with an exemplary and non-limiting embodiment, the mappingsystem employs multi-thread processing of scan matching. The scanmatching may utilize KD-tree building, point querying, matrix inversefor nonlinear optimization, and the like. Standard parallel processingsuch as openMP can only accelerate point querying and does not serve tosubstantially reduce overall time. In contrast, the present systemprocesses a different scan on each thread. In other words, the fourthreads process four consecutive scans instead of one scan.

In accordance with an exemplary and non-limiting embodiment, a methodcomprises accessing a data set comprising a LIDAR acquired point cloudcomprising a plurality of points each of which are attributed with atleast a geospatial coordinate, sub-sampling at least a portion of theplurality of points to derive a representative sample of the pluralityof points and displaying the representative sample of the plurality ofpoints.

In accordance with an exemplary and non-limiting embodiment, a methodcomprises acquiring a LIDAR point cloud comprising a plurality of pointseach of which are attributed with at least a geospatial coordinate and asegment, assigning a confidence level to each segment indicative of acomputed accuracy of the plurality of points attributed with the samesegment and displaying the assigned confidence levels to a user.

In accordance with an exemplary and non-limiting embodiment, a methodcomprises acquiring a LIDAR point cloud with a SLAM system comprising aplurality of points each of which are attributed with at least ageospatial coordinate and a timestamp, displaying at least a portion ofthe plurality of points, receiving an indication of a specified time towhich to rewind the acquisition of the point cloud and tagging a portionof the plurality of points each attributed with a timestamp after thespecified time.

In accordance with an exemplary and non-limiting embodiment, a methodcomprises acquiring a LIDAR point cloud with a SLAM system comprising aplurality of points each of which are attributed with at least ageospatial coordinate and a timestamp. displaying at least a portion ofthe plurality of points and displaying an indication to a user of aportion of the point cloud exhibiting a point density below apredetermined threshold.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a block diagram of an embodiment of a mapping system.

FIG. 2 illustrates an embodiment a block diagram of the threecomputational modules and their respective feedback features of themapping system of FIG. 1.

FIG. 3 illustrates an embodiment of a Kalmann filter model for refiningpositional information into a map.

FIG. 4 illustrates an embodiment of a factor graph optimization modelfor refining positional information into a map.

FIG. 5 illustrates an embodiment of a visual-inertial odometrysubsystem.

FIG. 6 illustrates an embodiment of a scan matching subsystem.

FIG. 7A illustrates an embodiment of a large area map having coarsedetail resolution.

FIG. 7B illustrates an embodiment of a small area map having fine detailresolution.

FIG. 8A illustrates an embodiment of multi-thread scan matching.

FIG. 8B illustrates an embodiment of single-thread scan matching.

FIG. 9A illustrates an embodiment of a block diagram of the threecomputational modules in which feedback data from the visual-inertialodometry unit is suppressed due to data degradation.

FIG. 9B illustrates an embodiment of the three computational modules inwhich feedback data from the scan matching unit is suppressed due todata degradation.

FIG. 10 illustrates an embodiment of the three computational modules inwhich feedback data from the visual-inertial odometry unit and the scanmatching unit are partially suppressed due to data degradation.

FIG. 11 illustrates an embodiment of estimated trajectories of a mobilemapping device.

FIG. 12 illustrates bidirectional information flow according to anexemplary and non-limiting embodiment.

FIGS. 13a and 13b illustrate a dynamically reconfigurable systemaccording to an exemplary and non-limiting embodiment.

FIG. 14 illustrates priority feedback for IMU bias correction accordingto an exemplary and non-limiting embodiment.

FIGS. 15a and 15b illustrate a two-layer voxel representation of a mapaccording to an exemplary and non-limiting embodiment.

FIGS. 16a and 16b illustrate multi-thread processing of scan matchingaccording to an exemplary and non-limiting embodiment.

FIGS. 17a and 17b illustrate exemplary and non-limiting embodiments of aSLAM system.

FIG. 18 illustrates an exemplary and non-limiting embodiment of a SLAMenclosure.

FIGS. 19a, 19b and 19c illustrate exemplary and non-limiting embodimentsof a point cloud showing confidence levels.

FIG. 20 illustrates an exemplary and non-limiting embodiment ofdiffering confidence level metrics.

FIG. 21 illustrates an exemplary and non-limiting embodiment of a SLAMsystem.

FIG. 22 illustrates an exemplary and non-limiting embodiment of timingsignals for the SLAM system.

FIG. 23 illustrates an exemplary and non-limiting embodiment of timingsignals for the SLAM system.

FIG. 24 illustrates an exemplary and non-limiting embodiment of SLAMsystem signal synchronization.

DETAILED DESCRIPTION

In one general aspect, the present invention is directed to a mobile,computer-based mapping system that estimates changes in position overtime (an odometer) and/or generates a three-dimensional maprepresentation, such as a point cloud, of a three-dimensional space. Themapping system may include, without limitation, a plurality of sensorsincluding an inertial measurement unit (IMU), a camera, and/or a 3Dlaser scanner. It also may comprise a computer system, having at leastone processor, in communication with the plurality of sensors,configured to process the outputs from the sensors in order to estimatethe change in position of the system over time and/or generate the maprepresentation of the surrounding environment. The mapping system mayenable high-frequency, low-latency, on-line, real-time ego-motionestimation, along with dense, accurate 3D map registration. Embodimentsof the present disclosure may include a simultaneous location andmapping (SLAM) system. The SLAM system may include a multi-dimensional(e.g., 3D) laser scanning and range measuring system that isGPS-independent and that provides real-time simultaneous location andmapping. The SLAM system may generate and manage data for a veryaccurate point cloud that results from reflections of laser scanningfrom objects in an environment. Movements of any of the points in thepoint cloud are accurately tracked over time, so that the SLAM systemcan maintain precise understanding of its location and orientation as ittravels through an environment, using the points in the point cloud asreference points for the location.

In one embodiment, the resolution of the position and motion of themobile mapping system may be sequentially refined in a series ofcoarse-to-fine updates. In a non-limiting example, discretecomputational modules may be used to update the position and motion ofthe mobile mapping system from a coarse resolution having a rapid updaterate, to a fine resolution having a slower update rate. For example, anIMU device may provide data to a first computational module to predict amotion or position of the mapping system at a high update rate. Avisual-inertial odometry system may provide data to a secondcomputational module to improve the motion or position resolution of themapping system at a lower update rate. Additionally, a laser scanner mayprovide data to a third computational, scan matching module to furtherrefine the motion estimates and register maps at a still lower updaterate. In one non-limiting example, data from a computational moduleconfigured to process fine positional and/or motion resolution data maybe fed back to computational modules configured to process more coarsepositional and/or motion resolution data. In another non-limitingexample, the computational modules may incorporate fault tolerance toaddress issues of sensor degradation by automatically bypassingcomputational modules associated with sensors sourcing faulty,erroneous, incomplete, or non-existent data. Thus, the mapping systemmay operate in the presence of highly dynamic motion as well as in dark,texture-less, and structure-less environments.

In contrast to existing map-generating techniques, which are mostlyoff-line batch systems, the mapping system disclosed herein can operatein real-time and generate maps while in motion. This capability offerstwo practical advantages. First, users are not limited to scanners thatare fixed on a tripod or other nonstationary mounting. Instead, themapping system disclosed herein may be associated with a mobile device,thereby increasing the range of the environment that may be mapped inreal-time. Second, the real-time feature can give users feedback forcurrently mapped areas while data are collected. The online generatedmaps can also assist robots or other devices for autonomous navigationand obstacle avoidance. In some non-limiting embodiments, suchnavigation capabilities may be incorporated into the mapping systemitself. In alternative non-limiting embodiments, the map data may beprovided to additional robots having navigation capabilities that mayrequire an externally sourced map.

There are several potential applications for the sensor, such as 3Dmodeling, scene mapping, and environment reasoning. The mapping systemcan provide point cloud maps for other algorithms that take point cloudsas input for further processing. Further, the mapping system can workboth indoors and outdoors. Such embodiments do not require externallighting and can operate in darkness. Embodiments that have a camera canhandle rapid motion, and can colorize laser point clouds with imagesfrom the camera, although external lighting may be required. The SLAMsystem can build and maintain a point cloud in real time as a user ismoving through an environment, such as when walking, biking, driving,flying, and combinations thereof. A map is constructed in real time asthe mapper progresses through an environment. The SLAM system can trackthousands of features as points. As the mapper moves, the points aretracked to allow estimation of motion. Thus, the SLAM system operates inreal time and without dependence on external location technologies, suchas GPS. In embodiments, a plurality (in most cases, a very large number)of features of an environment, such as objects, are used as points fortriangulation, and the system performs and updates many location andorientation calculations in real time to maintain an accurate, currentestimate of position and orientation as the SLAM system moves through anenvironment. In embodiments, relative motion of features within theenvironment can be used to differentiate fixed features (such as walls,doors, windows, furniture, fixtures and the like) from moving features(such as people, vehicles, and other moving items), so that the fixedfeatures can be used for position and orientation calculations.Underwater SLAM systems may use blue-green lasers to reduce attenuation.

The mapping system design follows an observation: drift in egomotionestimation has a lower frequency than a module's own frequency. Thethree computational modules are therefore arranged in decreasing orderof frequency. High-frequency modules are specialized to handleaggressive motion, while low-frequency modules cancel drift for theprevious modules. The sequential processing also favors computation:modules in the front take less computation and execute at highfrequencies, giving sufficient time to modules in the back for thoroughprocessing. The mapping system is therefore able to achieve a high levelof accuracy while running online in real-time.

Further, the system may be configured to handle sensor degradation. Ifthe camera is non-functional (for example, due to darkness, dramaticlighting changes, or texture-less environments) or if the laser isnon-functional (for example due to structure-less environments) thecorresponding module may be bypassed and the rest of the system may bestaggered to function reliably. The system was tested through a largenumber of experiments and results show that it can produce high accuracyover several kilometers of navigation and robustness with respect toenvironmental degradation and aggressive motion.

The modularized mapping system, disclosed below, is configured toprocess data from range, vision, and inertial sensors for motionestimation and mapping by using a multi-layer optimization structure.The modularized mapping system may achieve high accuracy, robustness,and low drift by incorporating features which may include:

-   -   an ability to dynamically reconfigure the computational modules;    -   an ability to fully or partially bypass failure modes in the        computational modules, and combine the data from the remaining        modules in a manner to handle sensor and/or sensor data        degradation, thereby addressing environmentally induced data        degradation and the aggressive motion of the mobile mapping        system; and    -   an ability to integrate the computational module cooperatively        to provide real-time performance.

Disclosed herein is a mapping system for online ego-motion estimationwith data from a 3D laser, a camera, and an IMU. The estimated motionfurther registers laser points to build a map of the traversedenvironment. In many real-world applications, ego-motion estimation andmapping must be conducted in real-time. In an autonomous navigationsystem, the map may be crucial for motion planning and obstacleavoidance, while the motion estimation is important for vehicle controland maneuver.

FIG. 1 depicts a simplified block diagram of a mapping system 100according to one embodiment of the present invention. Although specificcomponents are disclosed below, such components are presented solely asexamples and are not limiting with respect to other, equivalent, orsimilar components. The illustrated system includes an IMU system 102such as an Xsens® MTi-30 IMU, a camera system 104 such as an IDS®UI-1220SE monochrome camera, and a laser scanner 106 such as a VelodynePUCK™ VLP-16 laser scanner. The IMU 102 may provide inertial motion dataderived from one or more of an x-y-z accelerometer, a roll-pitch-yawgyroscope, and a magnetometer, and provide inertial data at a firstfrequency. In some non-limiting examples, the first frequency may beabout 200 Hz. The camera system 104 may have a resolution of about752×480 pixels, a 76° horizontal field of view (FOV), and a framecapture rate at a second frequency. In some non-limiting examples, theframe capture rate may operate at a second frequency of about 50 Hz. Thelaser scanner 106 may have a 360° horizontal FOV, a 30° vertical FOV,and receive 0.3 million points/second at a third frequency representingthe laser spinning rate. In some non-limiting examples, the thirdfrequency may be about 5 Hz. As depicted in FIG. 1, the laser scanner106 may be connected to a motor 108 incorporating an encoder 109 tomeasure a motor rotation angle. In one non-limiting example, the lasermotor encoder 109 may operate with a resolution of about 0.25°.

The IMU 102, camera 104, laser scanner 106, and laser scanner motorencoder 109 may be in data communication with a computer system 110,which may be any computing device, having one or more processors 134 andassociated memory 120, 160, having sufficient processing power andmemory for performing the desired odometry and/or mapping. For example,a laptop computer with 2.6 GHz i7quad-core processor (2 threads on eachcore and 8 threads overall) and an integrated GPU memory could be used.In addition, the computer system may have one or more types of primaryor dynamic memory 120 such as RAM, and one or more types of secondary orstorage memory 160 such as a hard disk or a flash ROM. Although specificcomputational modules (IMU module 122, visual-inertial odometry module126, and laser scanning module 132) are disclosed above, it should berecognized that such modules are merely exemplary modules having thefunctions as described above, and are not limiting. Similarly, the typeof computing device 110 disclosed above is merely an example of a typeof computing device that may be used with such sensors and for thepurposes as disclosed herein, and is in no way limiting.

As illustrated in FIG. 1, the mapping system 100 incorporates acomputational model comprising individual computational modules thatsequentially recover motion in a coarse-to-fine manner (see also FIG.2). Starting with motion prediction from an IMU 102 (IMU predictionmodule 122), a visual-inertial tightly coupled method (visual-inertialodometry module 126) estimates motion and registers laser pointslocally. Then, a scan matching method (scan matching refinement module132) further refines the estimated motion. The scan matching refinementmodule 132 also registers point cloud data 165 to build a map (voxel map134). The map also may be used by the mapping system as part of anoptional navigation system 136. It may be recognized that the navigationsystem 136 may be included as a computational module within the onboardcomputer system, the primary memory, or may comprise a separate systementirely.

It may be recognized that each computational module may process datafrom one of each of the sensor systems. Thus, the IMU prediction module122 produces a coarse map from data derived from the IMU system 102, thevisual-inertial odometry module 126 processes the more refined data fromthe camera system 104, and the scan matching refinement module 132processes the most fine-grained resolution data from the laser scanner106 and the motor encoder 109. In addition, each of the finer-grainedresolution modules further process data presented from a coarser-grainedmodule. The visual-inertial odometry module 126 refines mapping datareceived from and calculated by the IMU prediction module 122.Similarly, the scan matching refinement module 132, further processesdata presented by the visual inertial odometry module 126. As disclosedabove, each of the sensor systems acquires data at a different rate. Inone non-limiting example, the IMU 102 may update its data acquisition ata rate of about 200 Hz, the camera 104 may update its data acquisitionat a rate of about 50 Hz, and the laser scanner 106 may update its dataacquisition at a rate of about 5 Hz. These rates are non-limiting andmay, for example, reflect the data acquisition rates of the respectivesensors. It may be recognized that coarse-grained data may be acquiredat a faster rate than more fine-grained data, and the coarse-graineddata may also be processed at a faster rate than the fine-grained data.Although specific frequency values for the data acquisition andprocessing by the various computation modules are disclosed above,neither the absolute frequencies nor their relative frequencies arelimiting.

The mapping and/or navigational data may also be considered to comprisecoarse level data and fine level data. Thus, in the primary memory(dynamic memory 120), coarse positional data may be stored in a voxelmap 134 that may be accessible by any of the computational modules 122,126, 132. File detailed mapping data, as point cloud data 165 that maybe produced by the scan matching refinement module 132, may be storedvia the processor 150 in a secondary memory 160, such as a hard drive,flash drive, or other more permanent memory.

Not only are coarse-grained data used by the computational modules formore fine-grained computations, but both the visual-inertial odometrymodule 126 and the scan matching refinement module 132 (fine-gradepositional information and mapping) can feed back their more refinedmapping data to the IMU prediction module 122 via respective feedbackpaths 128 and 138 as a basis for updating the IMU position prediction.In this manner, coarse positional and mapping data may be sequentiallyrefined in resolution, and the refined resolution data serve asfeed-back references for the more coarse resolution computations.

FIG. 2 depicts a block diagram of the three computational modules alongwith their respective data paths. The IMU prediction module 122 mayreceive IMU positional data 223 from the IMU (102, FIG. 1). Thevisual-inertial odometry module 126 may receive the model data from theIMU prediction module 122 as well as visual data from one or moreindividually tracked visual features 227 a, 227 b from the camera (104,FIG. 1). The laser scanner (106, FIG. 1) may produce data related tolaser determined landmarks 233 a, 233 b, which may be supplied to thescan matching refinement module 132 in addition to the positional datasupplied by the visual-inertial odometry module 126. The positionalestimation model from the visual-inertial odometry module 126 may be fedback 128 to refine the positional model calculated by the IMU predictionmodule 122. Similarly, the refined map data from the scan matchingrefinement module 132 may be fed back 138 to provide additionalcorrection to the positional model calculated by the IMU predictionmodule 122.

As depicted in FIG. 2, and as disclosed above, the modularized mappingsystem may sequentially recover and refine motion related data in acoarse-to-fine manner. Additionally, the data processing of each modulemay be determined by the data acquisition and processing rate of each ofthe devices sourcing the data to the modules. Starting with motionprediction from an IMU, a visual-inertial tightly coupled methodestimates motion and registers laser points locally. Then, a scanmatching method further refines the estimated motion. The scan matchingrefinement module may also register point clouds to build a map. As aresult, the mapping system is time optimized to process each refinementphase as data become available.

FIG. 3 illustrates a standard Kalman filter model based on data derivedfrom the same sensor types as depicted in FIG. 1. As illustrated in FIG.3, the Kalman filter model updates positional and/or mapping data uponreceipt of any data from any of the sensors regardless of the resolutioncapabilities of the data. Thus, for example, the positional informationmay be updated using the visual-inertial odometry data at any time suchdata become available regardless of the state of the positionalinformation estimate based on the IMU data. The Kalman filter modeltherefore does not take advantage of the relative resolution of eachtype of measurement. FIG. 3 depicts a block diagram of a standard Kalmanfilter based method for optimizing positional data. The Kalman filterupdates a positional model 322 a-322 n sequentially as data arepresented. Thus, starting with an initial positional prediction model322 a, the Kalman filter may predict 324 a the subsequent positionalmodel 322 b. which may be refined based on the receive IMU mechanizationdata 323. The positional prediction model may be updated 322 b inresponse to the IMU mechanization data 323. in a prediction step 324 afollowed by update steps seeded with individual visual features or laserlandmarks.

FIG. 4 depicts positional optimization based on a factor-graph method.In this method, a pose of a mobile mapping system at a first time 410may be updated upon receipt of data to a pose at a second time 420. Afactor-graph optimization model combines constraints from all sensorsduring each refinement calculation. Thus, IMU data 323, feature data 327a, 327 b, and similar from the camera, and laser landmark data 333 a,333 b, and similar, are all used for each update step. It may beappreciated that such a method increases the computational complexityfor each positional refinement step due to the large amount of datarequired. Further, since the sensors may provide data at independentrates that may differ by orders of magnitude, the entire refinement stepis time bound to the data acquisition time for the slowest sensor. As aresult, such a model may not be suitable for fast real-time mapping. Themodularized system depicted in FIGS. 1 and 2 sequentially recoversmotion in a coarse-to-fine manner. In this manner, the degree of motionrefinement is determined by the availability of each type of data.

Assumptions, Coordinates, and Problem Assumptions and Coordinate Systems

As depicted above in FIG. 1, a sensor system of a mobile mapping systemmay include a laser 106, a camera 104, and an IMU 102. The camera may bemodeled as a pinhole camera model for which the intrinsic parameters areknown. The extrinsic parameters among all of the three sensors may becalibrated. The relative pose between the camera and the laser and therelative pose between the laser and the IMU may be determined accordingto methods known in the art. A single coordinate system may be used forthe camera and the laser. In one non-limiting example, the cameracoordinate system may be used, and all laser points may be projectedinto the camera coordinate system in pre-processing. In one non-limitingexample, the IMU coordinate system may be parallel to the cameracoordinate system and thus the IMU measurements may be rotationallycorrected upon acquisition. The coordinate systems may be defined asfollows:

-   -   the camera coordinate system {C} may originate at the camera        optical center, in which the x-axis points to the left, the        y-axis points upward, and the z-axis points forward coinciding        with the camera principal axis;    -   the IMU coordinate system {I} may originate at the IMU        measurement center, in which the x-, y-, and z-axes are parallel        to {C} and pointing in the same directions; and    -   the world coordinate system {W} may be the coordinate system        coinciding with {C} at the starting pose.

MAP Estimation Problem

A state estimation problem can be formulated as a maximum a posterior(MAP) estimation problem. We may define χ={x_(i)}, i∈{1; 2; . . . , m},as the set of system states U={u₁}, i∈{1; 2; . . . , m}, as the set ofcontrol inputs, and Z={z_(k)}, k∈{1; 2; . . . , n}, as the set oflandmark measurements. Given the proposed system, Z may be composed ofboth visual features and laser landmarks. The joint probability of thesystem is defined as follows,

$\begin{matrix}{{{P\left( {{\chi U},Z} \right)} \propto {{P\left( x_{0} \right)}{\prod\limits_{i = 1}^{m}\; {{P\left( {{x_{i}x_{i - 1}},u_{i}} \right)}{\prod\limits_{k = 1}^{n}\; {P\left( {z_{k}x_{i_{k}}} \right)}}}}}},} & {{Eq}.\mspace{14mu} 1}\end{matrix}$

where P(x₀) is a prior of the first system state, P(x_(i)|x_(i−1),u_(i))represents the motion model, and P(z_(k)|x_(ik)) represents the landmarkmeasurement model. For each problem formulated as (1), there is acorresponding Bayesian belief network representation of the problem. TheMAP estimation is to maximize Eq. 1. Under the assumption of zero-meanGaussian noise, the problem is equivalent to a least-square problem,

$\begin{matrix}{\chi^{*} = {{\arg \mspace{14mu} {\min\limits_{\chi}{\sum\limits_{i = 1}^{m}\; {r_{x_{i}}}^{2}}}} + {\sum\limits_{k = 1}^{n}\; {{r_{z_{k}}}^{2}.}}}} & {{Eq}.\mspace{14mu} 2}\end{matrix}$

Here, r_(xi) and r_(zk) are residual errors associated with the motionmodel and the landmark measurement model, respectively.

The standard way of solving Eq. 2 is to combine all sensor data, forexample visual features, laser landmarks, and IMU measurements, into alarge factor-graph optimization problem. The proposed data processingpipeline, instead, formulates multiple small optimization problems andsolves the problems in a coarse-to-fine manner. The optimization problemmay be restated as:

-   -   Problem: Given data from a laser, a camera, and an IMU,        formulate and solve problems as (2) to determine poses of {C}        with respect to {W}, then use the estimated poses to register        laser points and build a map of the traversed environment in        {W}.

IMU Prediction Subsystem IMU Mechanization

This subsection describes the IMU prediction subsystem. Since the systemconsiders {C} as the fundamental sensor coordinate system, the IMU mayalso be characterized with respect to {C}. As disclosed above in thesub-section entitled Assumptions and Coordinate Systems, {I} and {C} areparallel coordinate systems. ω(t) and a(t) may be two 3×1 vectorsindicating the angular rates and accelerations, respectively, of {C} attime t. The corresponding biases may be denoted as b_(ω)(t) and b_(a)(t)and n_(ω)(t) and n_(a)(t) be the corresponding noises. The vector, bias,and noise terms are defined in {C}. Additionally, g may be denoted asthe constant gravity vector in {W}. The IMU measurement terms are:

{circumflex over (ω)}(t)=ω(t)+b _(ω)(t)+n _(ω)(t),  Eq. 3

â(t)=a(t)−^(C) _(W) R(t)g− ^(I) _(C) t∥ω(t)∥² +b _(a)(t)+n _(a)(t),  Eq.4

where ^(C) _(W)R(t) is the rotation matrix from {W} to {C}, and ^(I)_(C)t is t the translation vector between {C} and {I}.

It is noted that the term ^(I) _(C)t∥ω(t)∥² represents the centrifugalforce due to the fact that the rotation center (origin of {C}) isdifferent from the origin of {I}. Some examples of visual-inertialnavigation methods model the motion in {I} to eliminate this centrifugalforce term. In the computational method disclosed herein, in whichvisual features both with and without depth information are used,converting features without depth from {C} to {I} is not straightforward (see below). As a result, the system disclosed herein models allof the motion in {C} instead. Practically, the camera and the IMU aremounted close to each other to maximally reduce effect of the term.

The IMU biases may be slowly changing variables. Consequently, the mostrecently updated biases are used for motion integration. First, Eq. 3 isintegrated over time. Then, the resulting orientation is used with Eq. 4for integration over time twice to obtain translation from theacceleration data.

Bias Correction

The IMU bias correction can be made by feedback from either the cameraor the laser (see 128, 138, respectively, in FIGS. 1 and 2). Eachfeedback term contains the estimated incremental motion over a shortamount of time. The biases may be modeled to be constant during theincremental motion. Starting with Eq. 3, b_(ω)(t) may be calculated bycomparing the estimated orientation with IMU integration. The updatedb_(ω)(t) is used in one more round of integration to re-compute thetranslation, which is compared with the estimated translation tocalculate b_(a)(t).

To reduce the effect of high-frequency noises, a sliding window isemployed keeping a known number of biases. Non-limiting examples of thenumber of biases used in the sliding window may include 200 to 1000biases with a recommended number of 400 biases based on a 200 Hz IMUrate. A non-limiting example of the number of biases in the slidingwindow with an IMU rate of 100 Hz is 100 to 500 with a typical value of200 biases. The averaged biases from the sliding window are used. Inthis implementation, the length of the sliding window functions as aparameter for determining an update rate of the biases. Althoughalternative methods to model the biases are known in the art, thedisclosed implementation is used in order to keep the IMU processingmodule as a separate and distinct module. The sliding window method mayalso allow for dynamic reconfiguration of the system. In this manner,the IMU can be coupled with either the camera, the laser, or both cameraand laser as required. For example, if the camera is non-functional, theIMU biases may be corrected only by the laser instead.

Visual-Inertial Odometry Subsystem

A block system diagram of the visual-inertial odometry subsystem isdepicted in FIG. 5. An optimization module 510 uses pose constraints 512from the IMU prediction module 520 along with camera constraints 515based on optical feature data having or lacking depth information formotion estimation 550. A depthmap registration module 545 may includedepthmap registration and depth association of the tracked camerafeatures 530 with depth information obtained from the laser points 540.The depthmap registration module 545 may also incorporate motionestimation 550 obtained from a previous calculation. The method tightlycouples vision with an IMU. Each provides constraints 512, 515,respectively, to an optimization module 510 that estimates incrementalmotion 550. At the same time, the method associates depth information tovisual features as part of the depthmap registration module 545. If afeature is located in an area where laser range measurements areavailable, depth is obtained from laser points. Otherwise, depth iscalculated from triangulation using the previously estimated motionsequence. As the last option, the method can also use features withoutany depth by formulating constraints in a different way. This is truefor those features which do not have laser range coverage or cannot betriangulated because they are not tracked long enough or located in thedirection of camera motion.

Camera Constraints

The visual-inertial odometry is a key-frame based method. A newkey-frame is determined 535 if more than a certain number of featureslose tracking or the image overlap is below a certain ratio. Here, rightsuperscript l, l∈Z⁺ may indicate the last key-frame, and c, c ∈Z⁺ andc>k, may indicate the current frame. As disclosed above, the methodcombines features with and without depth. A feature that is associatedwith depth at key-frame l, may be denoted as X_(l)=[x_(l), y_(l),z_(l)]^(T) in {C_(l)}. Correspondingly, a feature without depth isdenoted as X _(l)=[x _(l), y _(l), _(l)]^(T) using normalizedcoordinates instead. Note that X_(l), X _(l), x_(l), and x _(l) aredifferent from × and x in Eq.1 which represent the system state.Features at key-frames may be associated with depth for two reasons: 1)depth association takes some amount of processing, and computing depthassociation only at key-frames may reduce computation intensity; and 2)the depthmap may not be available at frame c and thus laser points maynot be registered since registration depends on an established depthmap.A normalized feature in {C_(c)} may be denoted as Xc=[x _(c), y _(c),1]^(T).

Let R_(l) ^(c) and t_(l) ^(c) be the 3×3 rotation matrix and 3×1translation vector between frames l and c, where R_(l) ^(c) ∈SO(3) andt_(l) ^(c) ∈

³, R_(l) ^(c) and T_(l) ^(c) form an SE(3) transformation. The motionfunction between frames l and c may be written as

X _(c) =R _(l) ^(c) X _(l) +t _(l) ^(c).  Eq. 5

X_(c) has an unknown depth. Let d_(c) be the depth, where X_(c)=d_(c) X_(c). Substituting X_(c) with d_(c) X _(c) and combining the 1st and 2ndrows with the 3rd row in Eq. 5 to eliminate d_(c), results in

(R(1)− x _(c) R(3))X _(l) +t ₁ −x _(c) t(3)=0,  Eq. 6

(R(2)− y _(c) R(3))X _(l) +t ₂ −y _(c) t(3)=0,  Eq. 7

R(h) and t(h), h∈{1, 2, 3}, are the h-th rows of R_(l) ^(c) and t_(l)^(c). In the case that depth in unavailable to a feature, let d_(l) bethe unknown depth at key-frame l. Substituting X_(l) and X_(c) withd_(k) X ₁ and d_(c) X _(c), respectively, and combining all three rowsin Eq. 5 to eliminate d_(k) and d_(c), results in another constraint,

[ y _(c) t(3)−t(2)],− x _(c) t(3)+t(1),{circumflex over (x)} _(c) t(2)−y _(c) t(1)]R _(l) ^(c) X _(l)=0.  Eq. 8

Motion Estimation

The motion estimation process 510 is required to solve an optimizationproblem combining three sets of constraints: 1) from features with knowndepth as in Eqs. 6-7; 2) from features with unknown depth as in Eq. 8;and 3) from the IMU prediction 520. T_(a) ^(b) may be defined as a 4×4transformation matrix between frames a and b,

$\begin{matrix}{{T_{a}^{b} = \begin{bmatrix}R_{a}^{b} & t_{a}^{b} \\0^{T} & 1\end{bmatrix}},} & {{Eq}.\mspace{14mu} 9}\end{matrix}$

where R_(a) ^(b) and t_(a) ^(b) are the corresponding rotation matrixand translation vector. Further, let θ_(a) ^(b) be a 3×1 vectorcorresponding to R_(a) ^(b) through an exponential map, where θ_(a) ^(b)∈so(3). The normalized term θ/∥θ∥ represents direction of the rotationand ∥θ∥ is the rotation angle. Each T_(a) ^(b) corresponds to a set ofθ_(a) ^(b) and t_(a) ^(b) containing 6-DOF motion of the camera.

The solved motion transform between frames l and c−1, namely T_(l)^(c−1) may be used to formulate the IMU pose constraints. A predictedtransform between the last two frames c−1 and c, denoted as {circumflexover (T)}_(c−1) ^(c) may be obtained from IMU mechanization. Thepredicted transform at frame c is calculated as,

{circumflex over (T)} _(l) ^(c) ={circumflex over (T)} _(c−1) ^(c) T_(l) ^(c−1).  Eq. 10

Let {circumflex over (θ)}_(l) ^(c) and {circumflex over (t)}_(l) ^(c) bethe 6-DOF motion corresponding to {circumflex over (T)}_(l) ^(c). It maybe understood that the IMU predicted translation, {circumflex over(t)}_(l) ^(c), is dependent on the orientation. As an example, theorientation may determine a projection of the gravity vector throughrotation matrix ^(C) _(W)R(t) in Eq. 4, and hence the accelerations thatare integrated. {circumflex over (t)}_(l) ^(c) may be formulated as afunction of θ_(l) ^(c), and may be rewriten as {circumflex over (t)}_(l)^(c)(θ_(l) ^(c)). It may be understood that the 200 Hz pose provided bythe IMU prediction module 122 (FIGS. 1 and 2) as well as the 50 Hz poseprovided by the visual-inertial odometry module 126 (FIGS. 1 and 2) areboth pose functions. Calculating {circumflex over (t)}_(l) ^(c)(θ_(l)^(c)) may begin at frame c and the accelerations may be integratedinversely with respect to time. Let θ_(l) ^(c) be the rotation vectorcorresponding to R_(l) ^(c) in Eq. 5, and θ_(l) ^(c) and t_(l) ^(c) arethe motion to be solved. The constraints may be expressed as,

Σ_(l) ^(c)[({circumflex over (θ)}_(l) ^(c)−θ_(l) ^(c))^(T),({circumflexover (t)} _(l) ^(c)(θ_(l) ^(c))−t _(l) ^(c))^(T)]^(T)=0,  Eq. 11

in which Σ_(l) ^(c) is a relative covariance matrix scaling the poseconstraints appropriately with respect to the camera constraints.

In the visual-inertial odometry subsystem, the pose constraints fulfillthe motion model and the camera constraints fulfill the landmarkmeasurement model in Eq. 2. The optimization problem may be solved byusing the Newton gradient-descent method adapted to a robust fittingframework for outlier feature removal. In this problem, the state spacecontains θ_(l) ^(c) and t_(l) ^(c). Thus, a full-scale MAP estimation isnot performed, but is used only to solve a marginalized problem. Thelandmark positions are not optimized, and thus only six unknowns in thestate space are used, thereby keeping computation intensity low. Themethod thus involves laser range measurements to provide precise depthinformation to features, warranting motion estimation accuracy. As aresult, further optimization of the features' depth through a bundleadjustment may not be necessary.

Depth Association

The depthmap registration module 545 registers laser points on adepthmap using previously estimated motion. Laser points 540 within thecamera field of view are kept for a certain amount of time. The depthmapis down-sampled to keep a constant density and stored in a 2D KD-treefor fast indexing. In the KD-tree, all laser points are projected onto aunit sphere around the camera center. A point is represented by its twoangular coordinates. When associating depth to features, features may beprojected onto the sphere. The three closest laser points are found onthe sphere for each feature. Then, their validity may be by calculatingdistances among the three points in Cartesian space. If a distance islarger than a threshold, the chance that the points are from differentobjects, e.g. a wall and an object in front of the wall, is high and thevalidity check fails. Finally, the depth is interpolated from the threepoints assuming a local planar patch in Cartesian space.

Those features without laser range coverage, if they are tracked over acertain distance and not located in the direction of camera motion, maybe triangulated using the image sequences where the features aretracked. In such a procedure, the depth may be updated at each framebased on a Bayesian probabilistic mode.

Scan Matching Subsystem

This subsystem further refines motion estimates from the previous moduleby laser scan matching. FIG. 6 depicts a block diagram of the scanmatching subsystem. The subsystem receives laser points 540 in a localpoint cloud and registers them 620 using provided odometry estimation550. Then, geometric features are detected 640 from the point cloud andmatched to the map. The scan matching minimizes the feature-to-mapdistances, similar to many methods known in the art. However, theodometry estimation 550 also provides pose constraints 612 in theoptimization 610. The optimization comprises processing pose constraintswith feature correspondences 615 that are found and further processedwith laser constraints 617 to produce a device pose 650. This pose 650is processed through a map registration process 655 that facilitatesfinding the feature correspondences 615. The implementation uses voxelrepresentation of the map. Further, it can dynamically configure to runon one to multiple CPU threads in parallel.

Laser Constraints

When receiving laser scans, the method first registers points from ascan 620 into a common coordinate system. m, m∈ Z⁺ may be used toindicate the scan number. It is understood that the camera coordinatesystem may be used for both the camera and the laser. Scan m may beassociated with the camera coordinate system at the beginning of thescan, denoted as {C_(m)}. To locally register 620 the laser points 540,the odometry estimation 550 from the visual-inertial odometry may betaken as key-points, and the IMU measurements may be used to interpolatein between the key-points.

Let P_(m) be the locally registered point cloud from scan m. Two sets ofgeometric features from P_(m) may be extracted: one on sharp edges,namely edge points and denoted as ε_(m), and the other on local planarsurfaces, namely planar points and denoted as

_(m). This is through computation of curvature in the local scans.Points whose neighbor points are already selected are avoided such aspoints on boundaries of occluded regions and points whose local surfacesare close to be parallel to laser beams. These points are likely tocontain large noises or change positions over time as the sensor moves.

The geometric features are then matched to the current map built. LetQ_(m−1) be the map point cloud after processing the last scan, Q_(m−1)is defined in {W}. The points in Q_(m−1) are separated into two setscontaining edge points and planar points, respectively. Voxels may beused to store the map truncated at a certain distance around the sensor.For each voxel, two 3D KD-trees may be constructed, one for edge pointsand the other for planar points. Using KD-trees for individual voxelsaccelerates point searching since given a query point, a specificKD-tree associated with a single voxel needs to be searched (see below).

When matching scans, ε_(m) and

_(m) into {W} are first projected using the best guess of motionavailable, then for each point in ε_(m) and

_(m), a cluster of closest points are found from the corresponding seton the map. To verify geometric distributions of the point clusters, theassociated eigenvalues and eigenvectors may be examined. Specifically,one large and two small eigenvalues indicate an edge line segment, andtwo large and one small eigenvalues indicate a local planar patch. Ifthe matching is valid, an equation is formulated regarding the distancefrom a point to the corresponding point cluster,

f(Xm,θm,tm)=d,  Eq. 12

where X_(m) is a point in ε_(m) or

_(m), θ_(m), θ_(m), ∈so(3), and t_(m), t_(m)∈

³, indicate the 6-DOF pose of {C_(m)} in {W}.

Motion Estimation

The scan matching is formulated into an optimization problem 610minimizing the overall distances described by Eq. 12. The optimizationalso involves pose constraints 612 from prior motion. Let T_(m−1) be the4×4 transformation matrix regarding the pose of {Cm−1} in {W}, T_(m−1)is generated by processing the last scan. Let {circumflex over(T)}_(m−1) ^(m) be the pose transform from {C_(m−1)} to {C_(m)}, asprovided by the odometry estimation. Similar to Eq. 10, the predictedpose transform of {C_(m)} in {W} is,

{circumflex over (T)} _(m) ={circumflex over (T)} _(m−1) ^(m) T_(m−1).  Eq. 13

Let {circumflex over (θ)}_(m) and {circumflex over (t)}_(m) be the 6-DOFpose corresponding to {circumflex over (T)}_(m), and let Σ_(m) be arelative covariance matrix. The constraints are,

Σ_(m)[({circumflex over (θ)}_(m)−θ_(m))^(T),({circumflex over (t)} _(m)−t _(m))^(T)]^(T)=0.  Eq. 14

Eq. 14 refers to the case that the prior motion is from thevisual-inertial odometry, assuming the camera is functional. Otherwise,the constraints are from the IMU prediction. {circumflex over (θ)}′_(m)and {circumflex over (t)}′_(m)(θ_(m)) may be used to denote the sameterms by IMU mechanization. {circumflex over (t)}′_(m)(θ_(m)) is afunction of θ_(m) because integration of accelerations is dependent onthe orientation (same with {circumflex over (t)}_(l) ^(c) (θ_(l) ^(c))in Eq. 11). The IMU pose constraints are,

Σ′_(m)[({circumflex over (θ)}′_(m)−θ_(m))^(T),({circumflex over (t)}′_(m)(θ_(m))−t _(m))^(T)]^(T)=0,  Eq. 15

where Σ′_(m) is the corresponding relative covariance matrix. In theoptimization problem, Eqs. 14 and 15 are linearly combined into one setof constraints. The linear combination is determined by working mode ofthe visual-inertial odometry. The optimization problem refines θ_(m) andt_(m), which is solved by the Newton gradient-descent method adapted toa robust fitting framework.

Map in Voxels

The points on the map are kept in voxels. A 2-level voxel implementationas illustrated in FIGS. 7A and 7B. M_(m−1) denotes the set of voxels702, 704 on the first level map 700 after processing the last scan.Voxels 704 surrounding the sensor 706 form a subset M_(m−1), denoted asS_(m−1). Given a 6-DOF sensor pose, {circumflex over (θ)}_(m) and{circumflex over (t)}_(m), there is a corresponding S_(m−1) which moveswith the sensor on the map. When the sensor approaches the boundary ofthe map, voxels on the opposite side 725 of the boundary are moved overto extend the map boundary 730. Points in moved voxels are clearedresulting in truncation of the map.

As illustrated in FIG. 7B, each voxel j,jε∈S_(m−1) of the second levelmap 750 is formed by a set of voxels that are a magnitude smaller,denoted as S_(m−1) ^(j) than those of the first level map 700. Beforematching scans, points in ε_(m) and

_(m) are projected onto the map using the best guess of motion, and fillthem into {S_(m−1) ^(j)}, j∈S_(m−1). Voxels 708 occupied by points fromε_(m) and

_(m) are extracted to form Q_(m−1) and stored in 3D KD-trees for scanmatching. Voxels 710 are those not occupied by points from ε_(m) or

_(m). Upon completion of scan matching, the scan is merged into thevoxels 708 with the map. After that, the map points are downsized tomaintain a constant density. It may be recognized that each voxel of thefirst level map 700 corresponds to a volume of space that is larger thana sub-voxel of the second level map 750. Thus, each voxel of the firstlevel map 700 comprises a plurality of sub-voxels in the second levelmap 750 and can be mapped onto the plurality of sub-voxels in the secondlevel map 750.

As noted above with respect to FIGS. 7A and 7B, two levels of voxels(first level map 700 and second level map 750) are used to store mapinformation. Voxels corresponding to M_(m−1) are used to maintain thefirst level map 700 and voxels corresponding to {S_(m−1) ^(j)},j∈S_(m−1) in the second level map 750 are used to retrieve the maparound the sensor for scan matching. The map is truncated only when thesensor approaches the map boundary. Thus, if the sensor navigates insidethe map, no truncation is needed. Another consideration is that twoKD-trees are used for each individual voxel in S_(m−1)—one for edgepoints and the other for planar points. As noted above, such a datastructure may accelerate point searching. In this manner, searchingamong multiple KD-trees is avoided as opposed to using two KD-trees foreach individual voxel in {S_(m−1) ^(j)}, j∈S_(m−1). The later requiresmore resources for KD-tree building and maintenance.

Table 1 compares CPU processing time using different voxel and KD-treeconfigurations. The time is averaged from multiple datasets collectedfrom different types of environments covering confined and open,structured and vegetated areas. We see that using only one level ofvoxels, M_(m−1), results in about twice of processing time for KD-treebuilding and querying. This is because the second level of voxels,{S_(m−1) ^(j)}, j∈S_(m−1), help retrieve the map precisely. Withoutthese voxel, more points are contained in Q_(m−1) and built into theKD-trees. Also, by using KD-trees for each voxel, processing time isreduced slightly in comparison to using KD-trees for all voxels inM_(m−1).

TABLE 1 Comparison of average CPU processing time on KD-tree operation1-level voxels 2-level voxels KD-trees KD-trees for all KD-trees for forall KD-trees for Task voxels each voxel voxels each voxel Build (timeper 54 ms 47 ms 24 ms 21 ms KD-tree) Query (time per 4.2 ns   4.1 ns  2.4 ns   2.3 ns   point)

Parallel Processing

The scan matching involves building KD-trees and repetitively findingfeature correspondences. The process is time-consuming and takes majorcomputation in the system. While one CPU thread cannot guarantee thedesired update frequency, a multi-thread implementation may addressissues of complex processing. FIG. 8A illustrates the case where twomatcher programs 812, 815 run in parallel. Upon receiving of a scan, amanager program 810 arranges it to match with the latest map available.In one example, composed of a clustered environment with multiplestructures and multiple visual features, matching is slow and may notcomplete before arrival of the next scan. The two matchers 812 and 815are called alternatively. In one matcher 812, P_(m), 813 a P_(m−2), 813b and additional P_(m−k) (for k=an even integer) 813 n, are matched withQ_(m−2) 813 a, Q_(m−4) 813 a, and additional Q_(m−k) (for k=an eveninteger) 813 n, respectively. Similarly, in a second matcher 815,P_(m+1), 816 a P_(m−1), 816 b and additional P_(m−k) (for k=an oddinteger) 816 n, are matched with Q_(m−1) 816 a, Q_(m−3) 816 a, andadditional Q_(m−k) (for k=an odd integer) 816 n, respectively, The useof this interleaving process may provide twice the amount of time forprocessing. In an alternative example, composed of a clean environmentwith few structures or visual features, computation is light. In such anexample (FIG. 8B), only a single matcher 820 may be called. Becauseinterleaving is not required P_(m), P_(m−1), . . . , are sequentiallymatched with Q_(m−1), Q_(m−2), . . . , respectively (see 827 a, 827 b,827 n). The implementation may be configured to use a maximum of fourthreads, although typically only two threads may be needed.

Transform Integration

The final motion estimation is integration of outputs from the threemodules depicted in FIG. 2. The 5 Hz scan matching output produces themost accurate map, while the 50 Hz visual-inertial odometry output andthe 200 Hz IMU prediction are integrated for high-frequency motionestimates.

On Robustness

The robustness of the system is determined by its ability to handlesensor degradation. The IMU is always assumed to be reliable functioningas the backbone in the system. The camera is sensitive to dramaticlighting changes and may also fail in a dark/texture-less environment orwhen significant motion blur is present (thereby causing a loss ofvisual features tracking). The laser cannot handle structure-lessenvironments, for example a scene that is dominant by a single plane.Alternatively, laser data degradation can be caused by sparsity of thedata due to aggressive motion.

Both the visual-inertial odometry and the scan matching modulesformulate and solve optimization problems according to EQ. 2. When afailure happens, it corresponds to a degraded optimization problem, i.e.constraints in some directions of the problem are ill-conditioned andnoise dominates in determining the solution. In one non-limiting method,eigenvalues, denoted as λ1, λ2, . . . , λ6, and eigenvectors, denoted asν₁, ν₂, . . . , ν₆, associated with the problem may be computed. Sixeigenvalues/eigenvectors are present because the state space of thesensor contains 6-DOF (6 degrees of freedom). Without losing generality,ν₁, ν₂, . . . , ν₆ may be sorted in decreasing order. Each eigenvaluedescribes how well the solution is conditioned in the direction of itscorresponding eigenvector. By comparing the eigenvalues to a threshold,well-conditioned directions may be separated from degraded directions inthe state space. Let h, h=0; 1, . . . , 6, be the number ofwell-conditioned directions. Two matrices may be defined as:

V=[ν ₁ , . . . , ν ₆]^(T) , V =[ν ₁ , . . . , ν _(h), 0, . . . ,0]^(T).  Eq. 16

When solving an optimization problem, the nonlinear iteration may startwith an initial guess. With the sequential pipeline depicted in FIG. 2,the IMU prediction provides the initial guess for the visual-inertialodometry, whose output is taken as the initial guess for the scanmatching. For the additional two modules (visual-inertial odometry andscan matching modules), let x be a solution and Δx be an update of x ina nonlinear iteration, in which Δx is calculated by solving thelinearized system equations. During the optimization process, instead ofupdating x in all directions, x may be updated only in well-conditioneddirections, keeping the initial guess in degraded directions instead,

x←x+V ⁻¹ VΔx.  Eq. 17

In Eq. 17, the system solves for motion in a coarse-to-fine order,starting with the IMU prediction, the additional two modules furthersolving/refining the motion as much as possible. If the problem iswell-conditioned, the refinement may include all 6-DOF. Otherwise, ifthe problem is only partially well-conditioned, the refinement mayinclude 0 to 5-DOF. If the problem is completely degraded, V becomes azero matrix and the previous module's output is kept.

Returning to the pose constraints described in Eqs. 14 and 15, it may beunderstood that the two equations are linearly combined in the scanmatching problem. As defined in Eq. 16, V_(V) and V _(V) denote thematrices containing eigenvectors from the visual-inertial odometrymodule, V _(V) represents well-conditioned directions in the subsystem,and V_(V)−V _(V) represents degraded directions. The combinedconstraints are,

Σ_(m) V _(V) ⁻¹ {circumflex over (V)} _(V)[({circumflex over(θ)}_(m)−θ_(m))^(T),({circumflex over (t)} _(m) −t_(tm))^(T)]^(T)+Σ′_(m) V _(V) ⁻¹

(V _(v) −{circumflex over (V)} _(V))[({circumflex over(θ)}′_(m)−θ_(m))^(T),({circumflex over (t)}′ _(m)(θ_(m))−t_(m))^(T)]^(T)=0.  Eq. 18

In a normal case where the camera is functional, {circumflex over(V)}_(V)=V_(V) and Eq.18 is composed of pose constraints from thevisual-inertial odometry as in Eq. 14. However, if the camera data arecompletely degraded, {circumflex over (V)}_(V) is a zero matrix and Eq.18 is composed of pose constraints from the IMU prediction according toEq. 15.

Case Study of Camera Degradation

As depicted in FIG. 9A, if visual features are insufficiently availablefor the visual-inertial odometry, the IMU prediction 122 bypasses thevisual-inertial odometry module 126 fully or partially 924—denoted bythe dotted line—depending on the number of well-conditioned directionsin the visual-inertial odometry problem. The scan matching module 132may then locally register laser points for the scan matching. Thebypassing IMU prediction is subject to drift. The laser feedback 138compensates for the camera feedback 128 correcting velocity drift andbiases of the IMU, only in directions where the camera feedback 128 isunavailable. Thus, the camera feedback has a higher priority, due to thehigher frequency making it more suitable when the camera data are notdegraded. When sufficient visual features are found, the laser feedbackis not used.

Case Study of Laser Degradation

As shown in FIG. 9B, if environmental structures are insufficient forthe scan matching 132 to refine motion estimates, the visual-inertialodometry module 126 output fully or partially bypasses the scan matchingmodule to register laser points on the map 930 as noted by the dottedline. If well-conditioned directions exist in the scan matching problem,the laser feedback contains refined motion estimates in thosedirections. Otherwise, the laser feedback becomes empty 138.

Case Study of Camera and Laser Degradation

In a more complex example, both the camera and the laser are degraded atleast to some extent. FIG. 10 depicts such an example. A vertical barwith six rows represents a 6-DOF pose where each row is a DOF (degree offreedom), corresponding to an eigenvector in EQ. 16. In this example,the visual-inertial odometry and the scan matching each updates a 3-DOFof motion, leaving the motion unchanged in the other 3-DOF. The IMUprediction 1022 a-f may include initial IMU predicted values 1002. Thevisual-inertial odometry updates 1004 some 3-DOF (1026 c, 1026 e, 10260resulting in a refined prediction 1026 a-1026 f. The scan matchingupdates 1006 some 3-DOF (1032 b, 1032 d, 10320 resulting in a furtherrefined prediction 1032 a-1032 f. The camera feedback 128 containscamera updates 1028 a-1028 f and the laser feedback 138 contains laserupdates 1038 a-1038 f, respectively. In reference to FIG. 10, cellshaving no shading (1028 a, 1028 b, 1028 d, 1038 a, 1038 c, 1038 e) donot contain any updating information from the respective modules. Thetotal update 1080 a-1080 f to the IMU prediction modules is acombination of the updates 1028 a-1028 f from the camera feedback 128and the updates 1038 a-1038 f from the laser feedback 138. In one ormore of the degrees of freedom in which feedback is available from boththe camera (for example 1028 f) and the laser (for example 1038 f), thecamera updates (for example 1028 f) may have priority over the laserupdates (for example 1038 f).

In practice, however, the visual-inertial odometry module and the scanmatching module may execute at different frequencies and each may haveits own degraded directions. IMU messages may be used to interpolatebetween the poses from the scan matching output. In this manner, anincremental motion that is time aligned with the visual-inertialodometry output may be created. Let θ_(c−1) ^(c) and t_(c−1) ^(c) be the6-DOF motion estimated by the visual-inertial odometry between framesc−1 and c, where θ_(c−1) ^(c) ∈so(3) and t_(c−1) ^(c) ∈

³. Let θ′_(c−1) ^(c) and t′_(c−1) ^(c) be the corresponding termsestimated by the scan matching after time interpolation. V_(V) and V_(V) may be the matrices defined in Eq. 16 containing eigenvectors fromthe visual-inertial odometry module, in which V _(V) representswell-conditioned directions, and V_(V)-V _(V) represents degradeddirections. Let V_(S) and and V_(S) be the same matrices from the scanmatching module. The following equation calculates the combinedfeedback, f_(c),

f _(c) =f _(V) +V _(V) ⁻¹(V _(V) −V _(V))f _(S),  Eq. 19

where f_(V) and f_(S) represent the camera and the laser feedback,

f _(V) =V _(V) ⁻¹({circumflex over (v)} _(V))[(θ_(c−1) ^(c))^(T),(t_(c−1) ^(c))^(T)]^(T),  Eq. 20

f _(s,) =V _(S) ⁻¹ {circumflex over (V)} _(S)[(θ′_(c−1) ^(c))^(T),(t′_(c−1) ^(c))^(T)]^(T).  Eq. 21

note that f_(C) only contains solved motion in a subspace of the statespace. The motion from the IMU prediction, namely θ_(c−1) ^(c) and{circumflex over (t)}_(c−1) ^(c), may be projected to the null space off_(C),

f _(I) =V _(V) ⁻¹(V _(V) −V _(V))V _(S) ⁻¹(V _(S) −V _(S))[({circumflexover (θ)}_(c−1) ^(c))^(T),(t _(c−1) ^(c))^(T)]^(T)  Eq. 22

{tilde over (θ)}_(c−1) ^(c)(b_(ω)(t)) and {tilde over (t)}_(c−1)^(c)(b_(ω)(t), b_(a)(t)) may be used to denote the IMU predicted motionformulated as functions of b_(ω)(t) and b_(a)(t) through integration ofEqs. 3 and 4. The orientation {tilde over (θ)}_(c−1) ^(c)(t)) is onlyrelevant to b_(ω)(t), but the translationt {tilde over (t)}_(c−1)^(c)(b_(ω)(t), b_(a)(t)) is dependent on both b_(ω)(t) and b_(a)(t). Thebiases can be calculated by solving the following equation,

[({tilde over (θ)}_(c−1) ^(c)(b _(ω)(t)))^(T),({tilde over (t)} _(c−1)^(c)(b _(ω)(t),b _(a)(t)))^(T)]^(T) =f _(C) +f _(I).  Eq. 23

When the system functions normally, f_(C) spans the state space, andV_(V)−V _(V) and V_(S)−V _(S) in Eq. 22 are zero matrices.Correspondingly, b_(ω)(t) and b_(a)(t) are calculated from f_(C). In adegraded case, the IMU predicted motion, {circumflex over (θ)}_(c−1)^(c) and {circumflex over (t)}_(c−1) ^(c), is used in directions wherethe motion is unsolvable (e.g. white row 1080 a of the combined feedbackin FIG. 10). The result is that the previously calculated biases arekept in these directions.

Experiments

Tests with Scanners

The odometry and mapping software system was validated on two sensorsuites. In a first sensor suite, a Velodyne LIDAR™ HDL-32E laser scanneris attached to a UI-1220SE monochrome camera and an Xsens® MTi-30 IMU.The laser scanner has 360° horizontal FOV, 40° vertical FOV, andreceives 0.7 million points/second at 5 Hz spinning rate. The camera isconfigured at the resolution of 752×480 pixels, 76° horizontal FOV, and50 Hz frame rate. The IMU frequency is set at 200 Hz. In a second sensorsuite, a Velodyne LIDAR™ VLP-16 laser scanner is attached to the samecamera and IMU. This laser scanner has 360° horizontal FOV, 30° verticalFOV, and receives 0.3 million points/second at 5 Hz spinning rate. Eachsensor suite is attached to a vehicle for data collection, which aredriven on streets and in off-road terrains, respectively.

For both sensor suites, a maximum of 300 Harris corners were tracked. Toevenly distribute the visual features, an image is separated into 5×6identical sub-regions, each sub-region providing up to 10 features. Whena feature loses tracking, a new feature is generated to maintain thefeature number in each sub region.

The software runs on a laptop computer with a 2.6 GHz i7 quad-coreprocessor (2 threads on each core and 8 threads overall) and anintegrated GPU, in a Linux® system running Robot Operating System (ROS).Two versions of the software were implemented with visual featuretracking running on GPU and CPU, respectively. The processing time isshown in Table 2. The time used by the visual-inertial odometry (126 inFIG. 2) does not vary much with respect to the environment or sensorconfiguration. For the GPU version, it consumes about 25% of a CPUthread executing at 50 Hz. For the CPU version, it takes about 75% of athread. The sensor first suite results in slightly more processing timethan the second sensor suite. This is because the scanner receives morepoints and the program needs more time to maintain the depthmap andassociate depth to the visual features.

The scan matching (132 in FIG. 2) consumes more processing time whichalso varies with respect to the environment and sensor configuration.With the first sensor suite, the scan matching takes about 75% of athread executing at 5 Hz if operated in structured environments. Invegetated environments, however, more points are registered on the mapand the program typically consumes about 135% of a thread. With thesecond sensor suite, the scanner receives fewer points. The scanmatching module 132 uses about 50-95% of a thread depending on theenvironment. The time used by the IMU prediction (132 in FIG. 2) isnegligible compared to the other two modules.

Accuracy Tests

Tests were conducted to evaluate accuracy of the proposed system. Inthese tests, the first sensor suite was used. The sensors were mountedon an off-road vehicle driving around a university campus. After 2.7 kmof driving within 16 minutes, a campus map was built. The average speedover the test was 2.8 m/s.

TABLE 2 Average CPU processing time using the first and second sensorsuites Scan Visual-inertial odometry Matching (time per image frame)(time per Environment Senor suite GPU Tracking CPU Tracking laser scan)First suite 4.8 ms 14.3 ms 148 ms Structured Second suite 4.2 ms 12.9 ms103 ms First suite 5.5 ms 15.2 ms 267 ms Vegetated Second suite 5.1 ms14.7 ms 191 ms

To evaluate motion estimation drift over the test, the estimatedtrajectory and registered laser points were aligned on a satelliteimage. Here, laser points on the ground are manually removed. It wasdetermined, by matching the trajectory with streets on the satelliteimage, that an upper bound of the horizontal error was <1:0 m. It wasalso determined, by comparing buildings on the same floor, that thevertical error was <2:0 m. This gives an overall relative position driftat the end to be <0:09% of the distance traveled. It may be understoodthat precision cannot be guaranteed for the measurements, hence only anupper bound of the positional drift was calculated.

Further, a more comprehensive test was conducted having the same sensorsmounted on a passenger vehicle. The passenger vehicle was driven onstructured roads for 9.3 km of travel. The path traverses vegetatedenvironments, bridges, hilly terrains, and streets with heavy traffic,and finally returns to the starting position. The elevation changes over70 m along the path. Except waiting for traffic lights, the vehiclespeed is between 9-18 m/s during the test. It was determined that abuilding found at both the start and the end of the path was registeredinto two. The two registrations occur because of motion estimation driftover the length of the path. Thus, the first registration corresponds tothe vehicle at the start of the test and the second registrationcorresponds to the vehicle at the end of the test. The gap was measuredto be <20 m, resulting in a relative position error at the end of <0:22%of the distance traveled.

Each module in the system contributes to the overall accuracy. FIG. 11depicts estimated trajectories in an accuracy test. A first trajectoryplot 1102 of the trajectory of a mobile sensor generated by thevisual-inertial odometry system uses the IMU module 122 and thevisual-inertial odometry module 126 (see FIG. 2). The configuration usedin the first trajectory plot 1102 is similar to that depicted in FIG.9B. A second trajectory plot 1104 is based on directly forwarding theIMU prediction from the IMU module 122 to the scan matching module, 132(see FIG. 2) bypassing the visual-inertial odometry. This configurationis similar to that depicted in FIG. 9A. A third trajectory plot 1108 ofthe complete pipeline is based on the combination of the IMU module 122,the visual inertial odometry module 126, and the scan matching module132 (see FIG. 2) has the least amount of drift. The position errors ofthe first two configurations, trajectory plot 1102 and 1104, are aboutfour and two times larger, respectively.

The first trajectory plot 1102 and the second trajectory plot 1104 canbe viewed as the expected system performance when encounteringindividual sensor degradation. If scan matching is degraded (see FIG.9B), the system reduces to a mode indicated by the first trajectory plot1102. If vision is degraded, (see FIG. 9A), the system reduces to a modeindicated by the second trajectory plot 1104. If none of the sensors isdegraded, (see FIG. 2) the system incorporates all of the optimizationfunctions resulting in the trajectory plot 1108. In another example, thesystem may take the IMU prediction as the initial guess and but run atthe laser frequency (5 Hz). The system produces a fourth trajectory plot1106. The resulting accuracy is only little better in comparison to thesecond trajectory plot 1104 which uses the IMU directly coupled with thelaser, passing the visual-inertial odometry. The result indicates thatfunctionality of the camera is not sufficiently explored if solving theproblem with all constraints stacked together.

Another accuracy test of the system included running mobile sensor atthe original 1× speed and an accelerated 2× speed. When running at 2×speed, every other data frame for all three sensors is omitted,resulting in much more aggressive motion through the test. The resultsare listed in Table 3. At each speed, the three configurations wereevaluated. At 2× speed, the accuracy of the visual-inertial odometry andthe IMU+scan matching configurations reduce significantly, by 0.54% and0.38% of the distance traveled in comparison to the accuracy at 1×speed. However, the complete pipeline reduces accuracy very little, onlyby 0.04%. The results indicate that the camera and the laser compensatefor each other keeping the overall accuracy. This is especially truewhen the motion is aggressive.

TABLE 3 Relative position errors as percentages of the distance traveled(Errors at 1x speed correspond to the trajectories in FIG. 11)Configuration 1x speed 2x speed Visual-inertial odometry 0.93% 1.47%IMU + scan matching 0.51% 0.89% Complete pipeline 0.22% 0.26%

With reference to FIG. 12, there is illustrated an exemplary andnon-limiting embodiment of bidirectional information flow. Asillustrated, three modules comprising an IMU prediction module, avisual-inertial odometry module and a scan-matching refinement modulesolve the problem step by step from coarse to fine. Data processing flowis from left to right passing the three modules respectively, whilefeedback flow is from right to left to correct the biases of the IMU.

With reference to FIGS. 13a and 13b , there is illustrated an exemplaryand non-limiting embodiment of a dynamically reconfigurable system. Asillustrated in FIG. 13a , if visual features are insufficient for thevisual-inertial odometry, the IMU prediction (partially) bypasses thevisual-inertial odometry module to register laser points locally. On theother hand, if, as illustrated in FIG. 13b , environmental structuresare insufficient for the scan matching, the visual-inertial odometryoutput (partially) bypasses the scan matching refinement module toregister laser points on the map.

With reference to FIG. 14, there is illustrated an exemplary andnon-limiting embodiment of priority feedback for IMU bias correction. Asillustrated, a vertical bar represents a 6-DOF pose and each row is aDOF. In a degraded case, starting with the IMU prediction on the leftwhere all six rows designated are “IMU”, the visual-inertial odometryupdates in 3-DOF where the rows become designated “camera”, then thescan matching updates in another 3-DOF where the rows turn designated“laser”. The camera and the laser feedback is combined as the verticalbar on the left. The camera feedback has a higher priority—“laser” rowsfrom the laser feedback are only filled in if “camera” rows from thecamera feedback are not present.

With reference to FIGS. 15a and 15b , there is illustrated an exemplaryand non-limiting embodiment of two-layer voxel representation of a map.There is illustrated voxels on the map M_(m−1) (all voxels in FIG. 15a), and voxels surrounding the sensor S_(m−1) (dot filled voxels).S_(m−1) is a subset of M_(m−1). If the sensor approaches the boundary ofthe map, voxels on the opposite side of the boundary (bottom row) aremoved over to extend the map boundary. Points in moved voxels arecleared and the map is truncated. As illustrated in FIG. 15b each voxelj, j∈S_(m−1) (a dot filled voxel in FIG. 15a ) is formed by a set ofvoxels s_(m−1) ^(j) that are a magnitude smaller (all voxels in (FIG.15b )∈S_(m−1) ^(j)). Before scan matching, the laser scan may beprojected onto the map using the best guess of motion. Voxels in{S_(m−1) ^(j)}, j∈S_(m−1) occupied by points from the scan are labeledin cross-hatch. Then, map points in cross-hatched voxels are extractedand stored in 3D KD-trees for scan matching.

With reference to FIG. 16, there is illustrated an exemplary andnon-limiting embodiment of multi-thread processing of scan matching. Asillustrated, a manager program calls multiple matcher programs runningon separate CPU threads and matches scans to the latest map available.FIG. 16a shows a two-thread case. Scans P_(m), P_(m−1), . . . , arematched with map Q_(m), Q_(m−1), . . . , on each matcher, giving twiceamount of time for processing. In comparison, FIG. 16b shows aone-thread case, where P_(m), P_(m−1), . . . , are matched with Q_(m),Q_(m−1), . . . . The implementation is dynamically configurable using upto four threads.

In embodiments, a real time SLAM system may be used in combination witha real time navigation system. In embodiments, the SLAM system may beused in combination with an obstacle detection system, such as a LIDAR-or RADAR-based obstacle detection system, a vision-based obstacledetection system, a thermal-based system, or the like. This may includedetecting live obstacles, such as people, pets, or the like, such as bymotion detection, thermal detection, electrical or magnetic fielddetection, or other mechanisms.

In embodiments, the point cloud that is established by scanning thefeatures of an environment may be displayed, such as on a screen forminga part of the SLAM, to show a mapping of a space, which may includemapping of near field features, such as objects providing nearbyreflections to the SLAM system, as well as far field features, such asitems that can be scanned through spaces between or apertures in thenear field features. For example, items in an adjacent hallway may bescanned through a window or door as the mapper moves through theinterior of a room, because at different points in the interior of theroom different outside elements can be scanned through such spaces orapertures. The resulting point cloud may then comprise comprehensivemapping data of the immediate near field environment and partial mappingof far field elements that are outside the environment. Thus, the SLAMsystem may include mapping of a space through a “picket fence” effect byidentification of far-field pieces through spaces or apertures (i.e.,gaps in the fence) in the near field. The far field data may be used tohelp the system orient the SLAM as the mapper moves from space to space,such as maintaining consistent estimation of location as the mappermoves from a comprehensively mapped space (where orientation andposition are well known due to the density of the point cloud) to asparsely mapped space (such as a new room). As the user moves from thenear field to a far field location, the relative density or sparsenessof the point cloud can be used by the SLAM system to guide the mappervia, for example, a user interface forming a part of the SLAM, such asdirecting the mapper to the parts of the far field that could not beseen through the apertures from another space.

In embodiments, the point cloud map from a SLAM system can be combinedwith mapping from other inputs such as cameras, sensors, and the like.For example, in a flight or spacecraft example, an airplane, drone, orother airborne mobile platform may already be equipped with otherdistance measuring and geo-location equipment that can be used asreference data for the SLAM system (such as linking the point cloudresulting from a scan to a GPS-referenced location) or that can takereference data from a scan, such as for displaying additional scan dataas an overlay on the output from the other system. For example,conventional camera output can be shown with point cloud data as anoverlay, or vice versa.

In embodiments, the SLAM system can provide a point cloud that includesdata indicating the reflective intensity of the return signal from eachfeature. This reflective intensity can be used to help determine theefficacy of the signal for the system, to determine how features relateto each other, to determine surface IR reflectivity, and the like. Inembodiments, the reflective intensity can be used as a basis formanipulating the display of the point cloud in a map. For example, theSLAM system can introduce (automatically, of under user control) somedegree of color contrast to highlight the reflectivity of the signal fora given feature, material, structure, or the like. In addition, thesystem can be married with other systems for augmenting color andreflectance information. In embodiments, one or more of the points inthe point cloud may be displayed with a color corresponding to aparameter of the acquired data, such as an intensity parameter, adensity parameter, a time parameter and a geospatial location parameter.Colorization of the point cloud may help users understand and analyzeelements or features of the environment in which the SLAM system isoperating and/or elements of features of the process of acquisition ofthe point cloud itself. For example, a density parameter, indicating thenumber of points acquired in a geospatial area, may be used to determinea color that represents areas where many points of data are acquired andanother color where data is sparse, perhaps suggesting the presence ofartifacts, rather than “real” data. Color may also indicate time, suchas progressing through a series of colors as the scan is undertaken,resulting in clear indication of the path by which the SLAM scan wasperformed. Colorization may also be undertaken for display purposes,such as to provide differentiation among different features (such asitems of furniture in a space, as compared to walls), to provideaesthetic effects, to highlight areas of interest (such as highlightinga relevant piece of equipment for attention of a viewer of a scan), anymany others.

In embodiments, the SLAM system can identify “shadows” (areas where thepoint cloud has relatively few data points from the scan) and can (suchas through a user interface) highlight areas that need additionalscanning. For example, such areas may blink or be rendered in aparticular color in a visual interface of a SLAM system that displaysthe point cloud until the shadowed area is sufficiently “painted,” orcovered, by laser scanning. Such an interface may include any indicator(visual, text-based, voice-based, or the like) to the user thathighlights areas in the field that have not yet been scanned, and anysuch indicator may be used to get the attention of the user eitherdirectly or through an external device (such as a mobile phone of theuser). In accordance with other exemplary and non-limiting embodiments,the system may make reference to external data of data stored on theSLAM, such as previously constructed point clouds, maps, and the like,for comparison with current scan to identify unscanned regions.

In embodiments, the methods and systems disclosed herein include a SLAMsystem that provides real-time positioning output at the point of work,without requiring processing or calculation by external systems in orderto determine accurate position and orientation information or togenerate a map that consists of point cloud data showing features of anenvironment based on the reflected signals from a laser scan. Inembodiments, the methods and systems disclosed herein may also include aSLAM system that provides real time positioning information withoutrequiring post-processing of the data collected from a laser scan.

In embodiments, a SLAM system may be integrated with various externalsystems, such as vehicle navigation systems (such as for unmanned aerialvehicles, drones, mobile robots, unmanned underwater vehicles,self-driving vehicles, semi-automatic vehicles, and many others). Inembodiments, the SLAM system may be used to allow a vehicle to navigatewithin its environments, without reliance on external systems like GPS.

In embodiments, a SLAM system may determine a level of confidence as toits current estimation of position, orientation, or the like. A level ofconfidence may be based on the density of points that are available in ascan, the orthogonality of points available in a scan, environmentalgeometries or other factors, or a combination thereof. The level ofconfidence may be ascribed to position and orientation estimates at eachpoint along the route of a scan, so that segments of the scan can bereferenced as low-confidence segments, high-confidence segments, or thelike. Low-confidence segments can be highlighted for additionalscanning, for use of other techniques (such as making adjustments basedon external data), or the like. For example, where a scan is undertakenin a closed loop (where the end point of the scan is the same as thestarting point, at a known origin location), any discrepancy between thecalculated end location and the starting location may be resolved bypreferentially adjusting location estimates for certain segments of thescan to restore consistency of the start- and end-locations. Locationand position information in low-confidence segments may bepreferentially adjusted as compared to high-confidence segments. Thus,the SLAM system may use confidence-based error correction for closedloop scans.

In an exemlary and non-limiting embodiment of this confidence-basedadjustment, a derivation of the incremental smoothing and mapping (iSAM)algorithm originally developed by Michael Kaess and Frank Dellaert atGeorgia Tech (“iSAM: Incremental Smoothing and Mapping” by M. Kaess, A.Ranganathan, and F. Dellaert, IEEE Trans. on Robotics, TRO, vol. 24, no.6, December 2008, pp. 1365-1378, PDF) may be used. This algorithmprocesses map data in “segments” and iteratively refines the relativeposition of those segments to optimize the residual errors of matchesbetween the segments. This enables closing loops by adjusting all datawithin the closed loop. More segmentation points allows the algorithm tomove the data more significantly while fewer segmentation pointsgenerates more rigidity.

If one selects the points for segmentation based on a matchingconfidence metric, one may utilize this fact to make the map flexible inregions with low confidence and rigid in areas with high confidence sothat the loop closure processing does not distribute local errorsthrough sections of the map that are accurate. This can be furtherenhanced by weighting the segmentation points to assign “flexibility” toeach point and distribute error based on this factor.

In embodiments, confidence measures with respect to areas or segments ofa point cloud may be used to guide a user to undertake additionalscanning, such as to provide an improved SLAM scan. In embodiments, aconfidence measure can be based on a combination of density of points,orthogonality of points and the like, which can be used to guide theuser to enable a better scan. It is noted that scan attributes, such asdensity of points and orthogonality of points, may be determined in realtime as the scan progresses. Likewise, the system may sense geometriesof the scanning environment that are likely to result in low confidencemeasures. For example, long hallways with smooth walls may not presentany irregularities to differentiate one scan segment from the next. Insuch instances, the system may assign a lower confidence measure to scandata acquired in such environments. The system can use various inputssuch as LIDAR, camera, and perhaps other sensors to determinediminishing confidence and guide the user through a scan withinstructions (such as “slow down,” “turn left” or the like). In otherembodiments, the system may display areas of lower than desiredconfidence to a user, such as via a user interface, while providingassistance in allowing the user to further scan the area, volume orregion of low confidence.

In embodiments, a SLAM output may be fused with other content, such asoutputs from cameras, outputs from other mapping technologies, and thelike. In embodiments, a SLAM scan may be conducted along with capture ofan audio track, such as via a companion application (optionally a mobileapplication) that captures time-coded audio notes that correspond to ascan. In embodiments, the SLAM system provides time-coding of datacollection during scanning, so that the mapping system can pinpoint whenand where the scan took place, including when and where the mapper tookaudio and/or notes. In embodiments, the time coding can be used tolocate the notes in the area of the map where they are relevant, such asby inserting data into a map or scan that can be accessed by a user,such as by clicking on an indicator on the map that audio is available.In embodiments, other media formats may be captured and synchronizedwith a scan, such as photography, HD video, or the like. These can beaccessed separately based on time information, or can be inserted atappropriate places in a map itself based on the time synchronization ofthe scan output with time information for the other media. Inembodiments, a user may use time data to go back in time and see whathas changed over time, such as based on multiple scans with differenttime-encoded data. Scans may be further enhanced with other information,such as date- or time-stamped service record data. Thus, a scan may bepart of a multi-dimensional database of a scene or space, where pointcloud data is associated with other data or media related to that scene,including time-based data or media. In embodiments, calculations aremaintained through a sequence of steps or segments in a manner thatallows a scan to be backed up, such as to return to a given point in thescan and re-initiate at that point, rather than having to re-initiate anew scan starting at the origin. This allows use of partial scaninformation as a starting point for continuing a scan, such as when aproblem occurs at a later point in a scan that was initially producinggood output. Thus, a user can “unzip” or “rewind” a scan back to apoint, and then recommence scanning from that point. The system canmaintain accurate position and location information based on the pointcloud features and can maintain time information to allow sequencingwith other time-based data. Time-based data can also allow editing of ascan or other media to synchronize them, such as where a scan wascompleted over time intervals and needs to be synchronized with othermedia that was captured over different time intervals. Data in a pointcloud may be tagged with timestamps, so that data with timestampsoccurring after a point in time to which a rewind is undertaken can beerased, such that the scan can re-commence from a designated point. Inembodiments, a rewind may be undertaken to a point in time and/or to aphysical location, such as rewinding to a geospatial coordinate.

In embodiments, the output from a SLAM-based map can be fused with othercontent, such as HD video, including by colorizing the point cloud andusing it as an overlay. This may include time-synchronization betweenthe SLAM system and other media capture system. Content may be fusedwith video, still images of a space, a CAD model of a space, audiocontent captured during a scan, metadata associated with a location, orother data or media.

In embodiments, a SLAM system may be integrated with other technologiesand platforms, such as tools that may be used to manipulate point clouds(e.g., CAD). This may include combining scans with features that aremodeled in CAD modeling tools, rapid prototyping systems, 3D printingsystems, and other systems that can use point cloud or solid model data.Scans can be provided as inputs to post-processing tools, such ascolorization tools. Scans can be provided to mapping tools, such as foradding points of interest, metadata, media content, annotations,navigation information, semantic analysis to distinguish particularshapes and/or identify objects, and the like.

Outputs can be combined with outputs from other scanning andimage-capture systems, such as ground penetrating radar, X-ray imaging,magnetic resonance imaging, computed tomography imaging, thermalimaging, photography, video, SONAR, RADAR, LIDAR and the like. This mayinclude integrating outputs of scans with displays for navigation andmapping systems, such as in-vehicle navigation systems, handheld mappingsystems, mobile phone navigation systems, and others. Data from scanscan be used to provide position and orientation data to other systems,including X, Y and Z position information, as well as pitch, roll andyaw information.

The data obtained from a real time SLAM system can be used for manydifferent purposes, including for 3D motion capture systems, foracoustics engineering applications, for biomass measurements, foraircraft construction, for archeology, for architecture, engineering andconstruction, for augmented reality (AR), for autonomous cars, forautonomous mobile robot applications, for cleaning and treatment, forCAD/CAM applications, for construction site management (e.g., forvalidation of progress), for entertainment, for exploration (space,mining, underwater and the like), for forestry (including for loggingand other forestry products like maple sugar management), for franchisemanagement and compliance (e.g., for stores and restaurants), forimaging applications for validation and compliance, for indoor location,for interior design, for inventory checking, for landscape architecture,for mapping industrial spaces for maintenance, for mapping truckingroutes, for military/intelligence applications, for mobile mapping, formonitoring oil pipelines and drilling, for property evaluation and otherreal estate applications, for retail indoor location (such as marryingreal time maps to inventory maps, and the like), for securityapplications, for stockpile monitoring (ore, logs, goods, etc.), forsurveying (including doing pre-scans to do better quoting), forUAVs/drones, for mobile robots, for underground mapping, for 3D modelingapplications, for virtual reality (including colorizing spaces), forwarehouse management, for zoning/planning applications, for autonomousmissions, for inspection applications, for docking applications(including spacecraft and watercraft), for cave exploration, and forvideo games/augmented reality applications, among many others. In alluse scenarios, the SLAM system may operate as described herein in thenoted areas of use.

In accordance with an exemplary and non-limiting embodiment, the unitcomprises hardware synchronization of the IMU, camera (vision) and theLiDAR sensor. The unit may be operated in darkness or structurelessenvironments for a duration of time. The processing pipeline may becomprised of modules. In darkness, the vision module may be bypassed. Instructureless environments, the LiDAR module may be bypassed orpartially bypassed. In exemplary and non-limiting embodiments, the IMU,Lidar and camera data are all time stamped and capable of beingtemporally matched and synchronized. As a result, the system can act inan automated fashion to synchronize image data and point cloud data. Insome instances, color data from synchronized camera images may be usedto color clod data pixels for display to the user.

The unit may comprise four CPU threads for scan matching and may run at,for example, 5 Hz with Velodyne data. The motion of the unit whenoperating may be relatively fast. For example, the unit may operate atangular speeds of approximately 360 degree/second and linear speeds ofapproximately 30 m/s.

The unit may localize to a prior generated map. For example, instead ofbuilding a map from scratch, the unit's software may refer to apreviously built map and produce sensor poses and a new map within theframework (e.g., geospatial or other coordinates) of the old map. Theunit can further extend a map using localization. By developing a newmap in the old map frame, the new map can go further on and out of theold map. This enables different modes of use including branching andchaining, in which an initial “backbone” scan is generated first andpotentially post-processed to reduce drift and/or other errors beforeresuming from the map to add local details, such as side rooms inbuilding or increased point density in a region of interest. By takingthis approach, the backbone model may be generated with extra care tolimit the global drift and the follow-on scans may be generated with thefocus on capturing local detail. It is also possible for multipledevices to perform the detailed scanning off of the same base map forfaster capture of a large region.

It is also possible to resume off of a model generated by a differenttype of device or even generated from a CAD drawing. For example, ahigher global accuracy stationary device could build a base map and amobile scanner could resume from that map and fill in details. In analternate embodiment, a longer range device may scan the outside andlarge inside areas of a building and a shorter range device may resumefrom that scan to add in smaller corridors and rooms and required finerdetails. Resuming from CAD drawings could have significant advantagesfor detecting differences between CAD and as-built rapidly.

Resuming may also provide location registered temporal data. Forexample, multiple scans may be taken of a construction site over time tosee the progress visually. In other embodiments multiple scans of afactory may help with tracking for asset management.

Resuming may alternately be used to purely provide localization datawithin the prior map. This may be useful for guiding a robotic vehicleor localizing new sensor data, such as images, thermal maps, acoustics,etc within an existing map.

In some embodiments, the unit employs relatively high CPU usage in amapping mode and relatively low CPU usage in a localization mode,suitable for long-time localization/navigation. In some embodiments, theunit supports long-time operations by executing an internal reset everyonce in a while. This is advantageous as some of the values generatedduring internal processing increase over time. Over a long period ofoperation (e.g., a few days), the values may reach a limit, such as alogical or physical limit of storage for the value in a computer,causing the processing, absent a reset, to potentially fail. In someinstances, the system may automatically flush RAM memory to improveperformance. In other embodiments, the system may selectively downsample older scanned data as might be necessary when performing a realtime comparison of newly acquired data with older and/or archived data.

In other exemplary embodiments, the unit may support a flyingapplication and aerial-ground map merging. In other embodiments, theunit may compute a pose output at the IMU frequency, e.g., 100 Hz. Insuch instances, the software may produce maps as well as sensor poses.The sensor poses tell the sensor position and pointing with respect tothe map being developed. High frequency and accurate pose output helpsin mobile autonomy because vehicle motion control requires such data.The unit further employs covariance and estimation confidence and maylock a pose when the sensor is static.

With reference to FIGS. 17(a)-17(b) there is illustrated exemplary andnon-limiting embodiments of a SLAM. LIDAR is rotated to create asubstantially hemispherical scan. This is performed by a mechanism witha DC motor driving a spur gear reduction to LIDAR mount via a spur gearassembly 1704. The spur gear reduction assembly 1704 enables the LIDARto be offset from the motor 1708. There is a slip ring in line with therotation of the LIDAR to provide power and receive data from thespinning LIDAR. An encoder 1706 is also in line with the rotation of theLIDAR to record the orientation of the mechanism during scanning. A thinsection contact bearing supports the LIDAR rotation shaft.Counterweights on the LIDAR rotation plate balance the weight about theaxis of rotation making the rotation smooth and constant. As depicted inthe LIDAR drive mechanism and attachment figures below, the mechanism isdesigned with minimal slop and backlash to enable maintenance of aconstant speed for interpolation of scan point locations. Note that amotor shaft 1710 is in physical communication with a LIDAR connector1712.

With reference to FIG. 18, there is illustrated an exemplary andnon-limiting embodiment of a SLAM enclosure 1802. The SLAM enclosure1802 is depicted in a variety of views and perspectives. Dimensions arerepresentative of an embodiment and non-limiting as the size may besimilar or different, while maintaining the general character andorientation of the major components, such as the LIDAR, odometry camera,colorization camera, user interface screen, and the like.

In some embodiments, the unit may employ a neck brace, shoulder brace,carrier, or other wearable element or device (not shown), such as tohelp an individual hold the unit while walking around. The unit or asupporting element or device may include one or more stabilizingelements to reduce shaking or vibration during the scan. In otherembodiments, the unit may employ a remote battery that is carried in ashoulder bag or the like to reduce the weight of the handheld unit,whereby the scanning device has an external power source.

In other embodiments, the cameras and LIDAR are arranged to maximize afield of view. The camera-laser arrangement poses a tradeoff. On oneside, the camera blocks the laser FOV and on the other side, the laserblocks the camera. In such an arrangement, both are blocked slightly butthe blocking does not significantly sacrifice the mapping quality. Insome embodiments, the camera points in the same direction as the laserbecause the vision processing is assisted by laser data. Laser rangemeasurements provide depth information to the image features in theprocessing.

In some embodiments, there may be employed a confidence metricrepresenting a confidence of spatial data. Such a confidence metricmeasurement may include, but is not limited to, number of points,distribution of points, orthogonality of points, environmental geometry,and the like. One or more confidence metrics may be computed for laserdata processing (e.g., scan matching) and for image processing. Withreference to FIGS. 19(a)-19(c), there are illustrated exemplary andnon-limiting example images showing point clouds differentiated by lasermatch estimation confidence. While in practice, such images may be colorcoded, as illustrated, both the trajectory and the points are renderedas solid or dotted in the cloud based on a last confidence value at thetime of recording. In the examples, dark gray is bad and light gray isgood. The values are thresholded such that everything with a value >10is solid. Through experimentation it has been found that with a Velodyne<1 is unreliable, <10 is less reliable, >10 is very good.

Using these metrics enables automated testing to resolve model issuesand offline model correction such as when utilizing a loop-closure toolas discussed elsewhere herein. Use of these metrics further enablesalerting the user when matches are bad and possibly auto-pausing,throwing out low confidence data, and alerting the user when scanning.FIG. 19(a) illustrates a scan of a building floor performed at arelatively slow pace. FIG. 19(b) illustrates a scan of the same buildingfloor performed at a relatively quicker pace. Note the prevalence oflight fray when compared to the scan acquired from a slower scan pacearising, in part, from the speed at which the scan is conducted. FIG.19(c) illustrates a display zoomed in on a potential trouble spot ofrelatively low confidence.

With reference to FIG. 20, there is illustrated an exemplary andnon-limiting embodiment of scan-to-scan match confidence metricprocessing and an average number of visual features that track between afull laser scan and a map being built from the prior full laser scansmay be computed and presented visually. This metric may present useful,but different confidence measures. In FIG. 20, a laser scan confidencemetric view is presented in the left frame while an average number ofvisual features metric is presented in the right frame for the samedata. Again, dark gray line indicates lower confidence and/or feweraverage number of visual features.

In some embodiments, there may be employed loop closure. For example,the unit may be operated as one walks around a room, cubicle, in and outof offices, and then back to a starting point. Ideally the mesh of datafrom the start and end point should mesh exactly. In the reality, theremay be some drift. The algorithms described herein greatly minimize suchdrift. Typical reduction is on the order of 10× versus conventionalmethods (0.2% v 2%). This ratio reflects the error in distance betweenthe start point and end point divided by the total distance traversedduring the loop. In some embodiments, the software recognizes that it isback to a starting point and it can relock to the origin. Once done, onemay take the variation and spread it over all of the collected data. Inother embodiments, one may lock in certain point cloud data where aconfidence metric indicates that the data confidence was poor and onemay apply the adjustments to the areas with low confidence.

In general, the system may employ both explicit and implicit loopclosure. In some instances, a user may indicate, such as via a userinterface forming a part of the SLAM, that a loop is to be closed. Thisexplicit loop closure may result in the SLAM executing software thatoperates to match recently scanned data to data acquired at thebeginning of the loop in order to snap the beginning and end acquireddata together and close the loop. In other embodiments, the system mayperform implicit loop closure. In such instances, the system may operatein an automated fashion to recognize that the system is activelyrescanning a location that that comprises a point or region of originfor the scan loop.

In some embodiments, there may be employed confidence-based loopclosure. First, one may determine a start and end point of a loop scanof an area that includes multiple segments. Then, one may determine aconfidence of a plurality of the multiple segments. One may then make anadjustment to the lower quality segments rather than the higher qualitysegments in order for the beginning and end of the loop to becoincident.

In other exemplary embodiments, there may be performed multi-loopconfidence-based loop closure. In yet other embodiments, there may beemployed semantically adjusted confidence-based loop closure. Forexample, structural information may be derived from the attribution of ascanned element, i.e., floors are flat, corridors are straight, etc.

In some instances, there may be employed colorization of LIDAR pointcloud data. In some embodiments, coarse colorization may be employed inreal time to collected points to help identify what has been captured.In other embodiments, off-line photorealistic colorization may beemployed. In other embodiments, each pixel in the camera can be mappedto a unique LIDAR pixel. For example, one may take color data from apixel in the colorization camera corresponding to LIDAR data in thepoint cloud, and add the color data to the LIDAR data.

In accordance with exemplary and non-limiting embodiments, the unit mayemploy a sequential, multi-layer processing pipeline, solving for motionfrom coarse to fine. In each layer of the optimization, the priorcoarser result is used as an initial guess to the optimization problem.The steps in the pipeline are:

1. Start with IMU mechanization for motion prediction, which provideshigh frequency updates (on order of 200 Hz), but is subject to highlevels of drift.

2. Then this estimate is refined by a visual-inertial odometryoptimization at the frame rate of the cameras (30-40 Hz), theoptimization problem uses the IMU motion estimate as an initial guess ofpose change and adjusts that pose change in an attempt to minimizeresidual squared errors in motion between several features tracked fromthe current camera frame to a key frame.

3. Then this estimate is further refined by a laser odometryoptimization at a lower rate determined by the “scan frame” rate. Scandata comes in continuously, and software segments that data into frames,similar to image frames, at a regular rate, currently that rate is thetime it takes for one rotation of the LIDAR rotary mechanism to makeeach scan frame a full hemisphere of data. That data is stitchedtogether using visual-inertial estimates of position change as thepoints within the same scan frame are gathered. In the LIDAR odometrypose optimization step the visual odometry estimate is taken as aninitial guess and the optimization attempts to reduce residual error intracked features in the current scan frame matched to the prior scanframe.

4. In the final step, the current scan frame is matched to the entiremap so far. The laser odometry estimate is taken as the initial guessand the optimization minimizes residual squared errors between featuresin the current scan frame and features in the map so far.

The resulting system enables high-frequency, low-latency ego-motionestimation, along with dense, accurate 3D map registration. Further, thesystem is capable of handling sensor degradation by automaticreconfiguration bypassing failure modules since each step can correcterrors in the prior step. Therefore, it can operate in the presence ofhighly dynamic motion as well as in dark, texture-less, andstructure-less environments. During experiments, the system demonstrates0.22% of relative position drift over 9.3 km of navigation androbustness with respect to running, jumping and even highway speeddriving (up to 33 m/s).

Other key features of such a system may include:

Visual Feature Optimization w/ and w/o Depth:

The software may attempt to determine a depth of tracked visualfeatures, first by attempting to associate them with the laser data andsecondly by attempting to triangulate depth between camera frames. Thefeature optimization software may then utilize all features with twodifferent error calculations, one for features with depth and one forfeatures without depth.

Laser Feature Determination:

The software may extract laser scan features as the scan line data comesin rather than in the entire scan frame. This is much easier and is doneby looking at the smoothness at each point, which is defined by therelative distance between that point and the K nearest points on eitherside of that point then labeling the smoothest points as planar featuresand the sharpest as edge features. It also allows for the deletion ofsome points that may be bad features.

Map Matching and Voxelization:

A part of how the laser matching works in real-time is how the map andfeature data is stored. Tracking the processor load of this stored datais critical to long term scanning and selectively voxelizing, ordown-sampling into three-deminsional basic units in order to minimizethe data stored while keeping what is needed for accurate matching.Adjusting the voxel sizes, or basic units, of this down-sampling on thefly based on processor load may improve the ability to maintainingreal-time performance in large maps.

Parallel Processing:

The software may be setup in such a way that it can utilize parallelprocessing to maintain real-time performance if data comes in fasterthan the processor can handle it. This is more relevant with fasterpoint/second LIDARS like the velodyne.

Robustness:

The way the system uses separate optimization steps without includingthe prior steps estimates as part of the next estimate (aside from beingthe initial guess) creates some inherent robustness.

Confidence Metrics:

Each optimization step in this process may provide information on theconfidence in its own results. In particular, in each step, thefollowing can be evaluated to provide a measure of confidence inresults: the remaining residual squared error after the optimization,the number of features tracked between frames, and the like.

The user may be presented a down scaled, (e.g., sub sampled) version ofthe multi-spectral model being prepared with data being acquired by thedevice. In an example, each measured 3 cm×3 cm×3 cm cube of model datamay be represented in the scaled down version presented on the userinterface as a single pixel. The pixel selected for display may be thepixel that is closest to the center of the cube. A representativedown-scaled display being generated during operation of the SLAM isshown below. As described, the decision to display a single pixel in avolume represents a binary result indicative of either the presence ofone or more points in a point cloud occupying a spatial cube of defineddimensions or the absence of any such points. In other exemplaryembodiments, the selected pixel may be attributed, such as with a valueindicating the number of pixels inside the defined cube represented bythe selected pixel. This attribute may be utilized when displaying thesub sampled point cloud such as by displaying each selected pixelutilizing color and/or intensity to reflect the value of the attribute.

A visual frame comprises a single 2D color image from the colorizationcamera. A LIDAR segment comprises s full 360 degree revolution of theLIDAR scanner. The visual frame and LIDAR segment are synchronized sothat they can be combined and aligned with the existing model data basedon the unit positional data captured from the IMU and related sensors,such as the odometry (e.g., a high speed black/white) camera.

Problems giving rise to lower confidence metrics include, but are notlimited to, reflections off of glossy walls, glass, transparent glassand narrow hallways. In some embodiments, a user of the unit may pauseand resume a scan such as by, for example, hitting a pause button and/orrequesting a rewind to a point that is a predetermined or requestednumber of seconds in the past.

In accordance with an exemplary and non-limiting embodiment, rewindingduring a scan may proceed as follows. First, the user of the systemindicates a desire to rewind. This may be achieved through themanipulation of user interface forming a part of the SLAM. As a resultof indicating a desire to rewind, the system deletes or otherwiseremoves a portion of scanned data points corresponding to a duration oftime. As all scanned data points are time stamped, the system caneffectively remove data points after a predetermined time, thus,“rewinding” back to a previous point in a scan. As discussed herein,images from the camera are gathered and time stamped during each scan.As a result, after removing data points after a predetermined point intime, the system may provide the user with a display of an imagerecorded at the predetermined point in time while displaying the scannedpoint cloud rewound to the predetermined point in time. The image actsas a guide to help the user of the system reorient the SLAM into aposition closely matching the orientation and pose of the SLAM at theprevious predetermined point in time. Once the user is oriented close tothe previous orientation of the SLAM at the predetermined point in time,the user may indicate a desire to resume scanning such as by engaging a“Go” button on a user interface of the SLAM. In response to the commandto resume scanning, the SLAM may proceed execute a processing pipelineutilizing newly scanned data to form an initial estimation of the SLAMsposition and orientation. During this process, the SLAM may not add newdata to the scan but, rather, may use the newly scanned data todetermine and display an instantaneous confidence level of the user'sposition as well as a visual representation of the extent to which newlyacquired data corresponds to the previous scan data. Lastly, once it isestablished that the SLAM's location and orientation are sufficientlydetermined with respect to the previously scanned data, scanning maycontinue.

As described above, this ability to rewind is enabled, in part, by thedata being stored. One may estimate how many points are brought in persecond and then estimate how much to “rewind”. The unit may inform theuser where he was x seconds a go and allow the user to move to thatlocation and take a few scans to confirm that the user is at theappropriate place. For example, the user may be told an approximateplace to go to (or the user indicate where they want to restart). If theuser is close enough, the unit may figure it out where the user is andtell the user if they are close enough.

In other exemplary embodiments, the unit may operate in transitionsbetween spaces. For example, If a user walks very quickly through anarrow doorway there may not be enough data and time to determine theuser's place in the new space. Specifically, in this example, theboundaries of a door frame may, prior to proceeding through it, blockthe LIDAR from imaging a portion of the environment beyond the doorsufficient to establish a user's location. One option is to detect thislowering of confidence metric and signal to the operator to modify hisbehavior upon approaching a narrow passage to slow down, such as by aflashing a visual indicator or a changing the color of the screen, andthe like.

With reference to FIG. 21, there is illustrated an exemplary andnon-limiting embodiment of a schematic of the SLAM unit 2100. The SLAMunit 2100 may include a timing server to generate multiple signalsderived from the IMU's 2106 pulse-per-second (PPS) signal. The generatedsignals may be used to synchronize the data collected from the differentsensors in the unit. A microcontroller 2102 may be used to generate thesignals and communicate with the CPU 2104. The quadrature decoder 2108may either be built into the microcontroller or on an external IC.

In some exemplary embodiments, the IMU 2206 supplies a rising edge PPSsignal that is used to generate the timing pulses for other parts of thesystem. The camera may receive three signals generated from the IMU PPSsignal including one rising edge signal as described above and twofalling edge signals, GPIO1 (lasting one frame) and GPIO2 (lasting twoframes as illustrated with reference to FIG. 22.

As illustrated, each camera receives a trigger signal synchronized withthe IMU PPS having a high frame rate of approximately 30 Hz or 40 Hz anda high resolution of approximately 0.5 Hz-5 Hz.

Each IMS PPS pulse may zero a counter internal to the microcontroller2202. The LIDAR's synchronous output may trigger the following events:

-   -   read the current encoder value through the quadrature decoder,        and    -   read the current counter value.

The encoder and the counter values may be saved together and sent to theCPU. This may happen every 40 Hz, dictated by the LIDAR synchronousoutput as illustrated with reference to FIG. 23.

An alternate time synchronization technique may include IMU basedpulse-per-second synchronization that facilitates synchronizing thesensors and the computer processor. An exemplary and non-limitingembodiment of this type of synchronization is depicted with reference toFIG. 24.

The IMU 2400 may be configured to send a Pulse Per Second (PPS) signal2406 to a LIDAR 2402. Every time a PPS is sent, the computer 2404 isnotified by recognizing a flag in the IMU data stream. Then, thecomputer 2404 follows up and sends a time string to the LIDAR 2402. TheLIDAR 2402 synchronizes to the PPS 2406 and encodes time stamps in theLIDAR data stream based on the received time strings.

Upon receiving the first PPS 2406, the computer 2404 records its systemtime. Starting from the second PPS, the computer 2404 increases therecorded time by one second, sends the resulting time string to theLIDAR 2402, and then corrects its own system time to track the PPS 2506.

In this time synchronization scheme, the IMU 2400 functions as the timeserver, while the initial time is obtained from the computer systemtime. The IMU 2400 data stream is associated with time stamps based onits own clock, and initialized with the computer system time when thefirst PPS 2406 is sent. Therefore, the IMU 2400, LIDAR 2402, andcomputer 2404 are all time synchronized. In embodiments, the LIDAR 2402may be a Velodyne LIDAR.

In accordance with exemplary and non-limiting embodiments, the unitincludes a COM express board and a single button interface for scanning.

In accordance with exemplary and non-limiting embodiments, the processIMU, vision and laser data sensors may be coupled. The unit may work indarkness or structureless environments for long periods of time. In someembodiments, four CPU threads may be employed for scan matching, eachrunning at 5 Hz with Velodyne data. As noted above, motion of the unitmay be fast and the unit may localize to a prior map and can extend amap using localization. The unit exhibits relatively high CPU usage inmapping mode and relatively low CPU usage in localization mode thusrendering it suitable for long-time.

The following clauses provide additonal statements regarding embodimentsas disclosed herein.

Clause 1. A method comprising: acquiring a LIDAR point cloud comprisinga plurality of points each of which are attributed with at least ageospatial coordinate and a segment, assigning a confidence level toeach segment indicative of a computed accuracy of the plurality ofpoints attributed with the same segment and adjusting the geospatialcoordinate of each of at least a portion of the plurality of pointsattributed with the same segment based, at least in part, on aconfidence level.

Clause 2. The method of clause 1, wherein the confidence level is aconfidence level of loop closure.

Clause 3. The method of clause 1, wherein adjusting the geospatialcoordinate is in response to a determined loop closure error.

Clause 4. The method of clause 1, wherein a segment for adjusting thegeospatial coordinate has a lower confidence level than at least oneother segment.

Clause 5. A method comprising: commencing to acquire a LIDAR point cloudwith a SLAM the point cloud having a starting location and comprising aplurality of points each of which are attributed with at least ageospatial coordinate and a segment, traversing a loop while acquiringthe LIDAR point cloud and determining a scan end point when the SLAM isin proximity to the starting location.

Clause 6. The method of clause 6, wherein determining the scan end pointcomprises receiving an indication from a user of the SLAM that the loophas been traversed.

Clause 7. The method of clause 6, wherein determining the scan end pointis based on points in a segment exhibiting a proximity to the startinglocation.

Clause 8. The method of clause 6, wherein points in a segment other thana segment comprising the starting location are attributed with ageospatial coordinate that is proximal to the starting location.

Clause 9. A method comprising: acquiring a LIDAR point cloud comprisinga plurality of points each of which are attributed with at least ageospatial coordinate and a timestamp, acquiring color image datacomprising a plurality of images each of which are attributed with atleast one of the geospatial coordinates and the timestamp and colorizingat least a portion of the plurality of points with color informationderived from an image having a timestamp that is close in time to thetimestamp of each point being colorized and having a geospatialcoordinate that is close in proximity to the geospatial coordinate ofthe colorized plurality of points.

Clause 10. The method of clause 9, wherein the colorizing is performedin one of real time and near real time.

Clause 11. A method comprising: deriving a motion estimate for a SLAMsystem using an IMU forming a part of the SLAM system, refining themotion estimate via a visual-inertial odometry optimization process toproduce a refined estimate and refining the refined estimate via a laserodometry optimization process by minimizing at least one residualsquared error between at least one feature in a current scan and atleast one previously scanned feature.

Clause 12. The method of clause 11, wherein deriving the motion estimatecomprises receiving IMU updates at a frequency of approximately 200 Hz.

Clause 13. The method of clause 12, wherein a frequency of the IMUupdates are between 190 Hz and 210 Hz.

Clause 14. The method of clause 11, wherein refining the motion estimatecomprises refining the motion estimate at a rate equal to a frame rateof a camera forming a part of the SLAM system.

Clause 15. The method of clause 14, wherein the frame rate is between 30Hz and 40 Hz.

Clause 16. The method of clause 11, wherein the laser odometryoptimization process is performed at a scan frame rate at which a LIDARrotary mechanism forming a part of the SLAM scans a full hemisphere ofdata.

Clause 17. A method comprising: acquiring a plurality of depth trackedvisual features in a plurality of camera frames using a camera forming apart of a SLAM system, associating the plurality of visual features witha LIDAR derived point cloud acquired from a LIDAR forming a part of theSLAM and triangulating a depth of at least one visual feature between atleast two camera frames.

Clause 18. The method of clause 17, where in the associating andtriangulating steps are performed on a processor employing parallelcomputing.

Clause 19. A SLAM device comprising: a microcontroller, an inertialmeasurement unit (IMU) adapted to produce a plurality of timing signalsand a timing server adapted to generate a plurality of synchronizationsignals derived from the plurality of timing signals, wherein thesynchronization signals operate to synchronize at least two sensorsforming a part of the SLAM device.

Clause 20. The SLAM device of clause 20, wherein the at least twosensors are selected from the group consisting of LIDAR, a camera and anIMU.

Clause 21. A method comprising: acquiring a LIDAR point cloud comprisinga plurality of points each of which are attributed with at least ageospatial coordinate and a timestamp, acquiring color image datacomprising a plurality of images each of which are attributed with atleast the geospatial coordinate and the timestamp, colorizing at least aportion of the plurality of points with color information derived froman image having at least one of a timestamp that is close in time to thetimestamp of each point being colorized and a geospatial coordinate thatis close in distance to the geospatial coordinate of each point beingcolorized and displaying the colorized portion of the plurality ofpoints.

Clause 22. The method of clause 21, further comprising displaying outputfrom a camera as an overlay on the displayed plurality of points.

Clause 23. A method comprising acquiring a LIDAR point cloud comprisinga plurality of points each of which are attributed with at least ageospatial coordinate and a timestamp and colorizing at least a portionof the plurality of points with color information, wherein each of theplurality of points is colorized with a color corresponding to aparameter of the acquired LIDAR point cloud data selected from the groupconsisting of an intensity parameter, a density parameter, a timeparameter and a geospatial location parameter.

Clause 24. A method comprising: acquiring a LIDAR point cloud with aSLAM comprising a plurality of near field points derived from acorresponding near environment and a plurality of far field pointsderived from a corresponding far field environment wherein the far fieldpoints are scanned through one or more spaces between one or moreelements located in the near environment and utilizing the plurality offar field points to orient the SLAM as it moves form the nearenvironment to the far environment.

While only a few embodiments of the present disclosure have been shownand described, it will be obvious to those skilled in the art that manychanges and modifications may be made thereunto without departing fromthe spirit and scope of the present disclosure as described in thefollowing claims. All patent applications and patents, both foreign anddomestic, and all other publications referenced herein are incorporatedherein in their entireties to the full extent permitted by law.

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer software, program codes,and/or instructions on a processor. The present disclosure may beimplemented as a method on the machine, as a system or apparatus as partof or in relation to the machine, or as a computer program productembodied in a computer readable medium executing on one or more of themachines. In embodiments, the processor may be part of a server, cloudserver, client, network infrastructure, mobile computing platform,stationary computing platform, or other computing platform. A processormay be any kind of computational or processing device capable ofexecuting program instructions, codes, binary instructions and the like.The processor may be or may include a signal processor, digitalprocessor, embedded processor, microprocessor or any variant such as aco-processor (math co-processor, graphic co-processor, communicationco-processor and the like) and the like that may directly or indirectlyfacilitate execution of program code or program instructions storedthereon. In addition, the processor may enable execution of multipleprograms, threads, and codes. The threads may be executed simultaneouslyto enhance the performance of the processor and to facilitatesimultaneous operations of the application. By way of implementation,methods, program codes, program instructions and the like describedherein may be implemented in one or more thread. The thread may spawnother threads that may have assigned priorities associated with them;the processor may execute these threads based on priority or any otherorder based on instructions provided in the program code. The processor,or any machine utilizing one, may include non-transitory memory thatstores methods, codes, instructions and programs as described herein andelsewhere. The processor may access a non-transitory storage mediumthrough an interface that may store methods, codes, and instructions asdescribed herein and elsewhere. The storage medium associated with theprocessor for storing methods, programs, codes, program instructions orother type of instructions capable of being executed by the computing orprocessing device may include but may not be limited to one or more of aCD-ROM, DVD, memory, hard disk, flash drive, RAM, ROM, cache and thelike.

A processor may include one or more cores that may enhance speed andperformance of a multiprocessor. In embodiments, the process may be adual core processor, quad core processors, other chip-levelmultiprocessor and the like that combine two or more independent cores(called a die).

The methods and systems described herein may be deployed in part or inwhole through a machine that executes computer software on a server,client, firewall, gateway, hub, router, or other such computer and/ornetworking hardware. The software program may be associated with aserver that may include a file server, print server, domain server,internet server, intranet server, cloud server, and other variants suchas secondary server, host server, distributed server and the like. Theserver may include one or more of memories, processors, computerreadable media, storage media, ports (physical and virtual),communication devices, and interfaces capable of accessing otherservers, clients, machines, and devices through a wired or a wirelessmedium, and the like. The methods, programs, or codes as describedherein and elsewhere may be executed by the server. In addition, otherdevices required for execution of methods as described in thisapplication may be considered as a part of the infrastructure associatedwith the server.

The server may provide an interface to other devices including, withoutlimitation, clients, other servers, printers, database servers, printservers, file servers, communication servers, distributed servers,social networks, and the like. Additionally, this coupling and/orconnection may facilitate remote execution of program across thenetwork. The networking of some or all of these devices may facilitateparallel processing of a program or method at one or more locationwithout deviating from the scope of the disclosure. In addition, any ofthe devices attached to the server through an interface may include atleast one storage medium capable of storing methods, programs, codeand/or instructions. A central repository may provide programinstructions to be executed on different devices. In thisimplementation, the remote repository may act as a storage medium forprogram code, instructions, and programs.

The software program may be associated with a client that may include afile client, print client, domain client, internet client, intranetclient and other variants such as secondary client, host client,distributed client and the like. The client may include one or more ofmemories, processors, computer readable media, storage media, ports(physical and virtual), communication devices, and interfaces capable ofaccessing other clients, servers, machines, and devices through a wiredor a wireless medium, and the like. The methods, programs, or codes asdescribed herein and elsewhere may be executed by the client. Inaddition, other devices required for execution of methods as describedin this application may be considered as a part of the infrastructureassociated with the client.

The client may provide an interface to other devices including, withoutlimitation, servers, other clients, printers, database servers, printservers, file servers, communication servers, distributed servers andthe like. Additionally, this coupling and/or connection may facilitateremote execution of program across the network. The networking of someor all of these devices may facilitate parallel processing of a programor method at one or more location without deviating from the scope ofthe disclosure. In addition, any of the devices attached to the clientthrough an interface may include at least one storage medium capable ofstoring methods, programs, applications, code and/or instructions. Acentral repository may provide program instructions to be executed ondifferent devices. In this implementation, the remote repository may actas a storage medium for program code, instructions, and programs.

The methods and systems described herein may be deployed in part or inwhole through network infrastructures. The network infrastructure mayinclude elements such as computing devices, servers, routers, hubs,firewalls, clients, personal computers, communication devices, routingdevices and other active and passive devices, modules and/or componentsas known in the art. The computing and/or non-computing device(s)associated with the network infrastructure may include, apart from othercomponents, a storage medium such as flash memory, buffer, stack, RAM,ROM and the like. The processes, methods, program codes, instructionsdescribed herein and elsewhere may be executed by one or more of thenetwork infrastructural elements. The methods and systems describedherein may be adapted for use with any kind of private, community, orhybrid cloud computing network or cloud computing environment, includingthose which involve features of software as a service (SaaS), platformas a service (PaaS), and/or infrastructure as a service (IaaS).

The methods, program codes, and instructions described herein andelsewhere may be implemented on a cellular network has sender-controlledcontact media content item multiple cells. The cellular network mayeither be frequency division multiple access (FDMA) network or codedivision multiple access (CDMA) network. The cellular network mayinclude mobile devices, cell sites, base stations, repeaters, antennas,towers, and the like. The cell network may be a GSM, GPRS, 3 G, EVDO,mesh, or other networks types.

The methods, program codes, and instructions described herein andelsewhere may be implemented on or through mobile devices. The mobiledevices may include navigation devices, cell phones, mobile phones,mobile personal digital assistants, laptops, palmtops, netbooks, pagers,electronic books readers, music players and the like. These devices mayinclude, apart from other components, a storage medium such as a flashmemory, buffer, RAM, ROM and one or more computing devices. Thecomputing devices associated with mobile devices may be enabled toexecute program codes, methods, and instructions stored thereon.Alternatively, the mobile devices may be configured to executeinstructions in collaboration with other devices. The mobile devices maycommunicate with base stations interfaced with servers and configured toexecute program codes. The mobile devices may communicate on apeer-to-peer network, mesh network, or other communications network. Theprogram code may be stored on the storage medium associated with theserver and executed by a computing device embedded within the server.The base station may include a computing device and a storage medium.The storage device may store program codes and instructions executed bythe computing devices associated with the base station.

The computer software, program codes, and/or instructions may be storedand/or accessed on machine readable media that may include: computercomponents, devices, and recording media that retain digital data usedfor computing for some interval of time; semiconductor storage known asrandom access memory (RAM); mass storage typically for more permanentstorage, such as optical discs, forms of magnetic storage like harddisks, tapes, drums, cards and other types; processor registers, cachememory, volatile memory, non-volatile memory; optical storage such asCD, DVD; removable media such as flash memory (e.g. USB sticks or keys),floppy disks, magnetic tape, paper tape, punch cards, standalone RAMdisks, Zip drives, removable mass storage, off-line, and the like; othercomputer memory such as dynamic memory, static memory, read/writestorage, mutable storage, read only, random access, sequential access,location addressable, file addressable, content addressable, networkattached storage, storage area network, bar codes, magnetic ink, and thelike.

The methods and systems described herein may transform physical and/oror intangible items from one state to another. The methods and systemsdescribed herein may also transform data representing physical and/orintangible items from one state to another.

The elements described and depicted herein, including in flow charts andblock diagrams throughout the figures, imply logical boundaries betweenthe elements. However, according to software or hardware engineeringpractices, the depicted elements and the functions thereof may beimplemented on machines through computer executable media haasender-controlled contact media content item a processor capable ofexecuting program instructions stored thereon as a monolithic softwarestructure, as standalone software modules, or as modules that employexternal routines, code, services, and so forth, or any combination ofthese, and all such implementations may be within the scope of thepresent disclosure. Examples of such machines may include, but may notbe limited to, personal digital assistants, laptops, personal computers,mobile phones, other handheld computing devices, medical equipment,wired or wireless communication devices, transducers, chips,calculators, satellites, tablet PCs, electronic books, gadgets,electronic devices, devices haa sender-controlled contact media contentitem artificial intelligence, computing devices, networking equipment,servers, routers and the like. Furthermore, the elements depicted in theflow chart and block diagrams or any other logical component may beimplemented on a machine capable of executing program instructions.Thus, while the foregoing drawings and descriptions set forth functionalaspects of the disclosed systems, no particular arrangement of softwarefor implementing these functional aspects should be inferred from thesedescriptions unless explicitly stated or otherwise clear from thecontext. Similarly, it will be appreciated that the various stepsidentified and described above may be varied, and that the order ofsteps may be adapted to particular applications of the techniquesdisclosed herein. All such variations and modifications are intended tofall within the scope of this disclosure. As such, the depiction and/ordescription of an order for various steps should not be understood torequire a particular order of execution for those steps, unless requiredby a particular application, or explicitly stated or otherwise clearfrom the context.

The methods and/or processes described above, and steps associatedtherewith, may be realized in hardware, software or any combination ofhardware and software suitable for a particular application. Thehardware may include a general-purpose computer and/or dedicatedcomputing device or specific computing device or particular aspect orcomponent of a specific computing device. The processes may be realizedin one or more microprocessors, microcontrollers, embeddedmicrocontrollers, programmable digital signal processors or otherprogrammable device, along with internal and/or external memory. Theprocesses may also, or instead, be embodied in an application specificintegrated circuit, a programmable gate array, programmable array logic,or any other device or combination of devices that may be configured toprocess electronic signals. It will further be appreciated that one ormore of the processes may be realized as a computer executable codecapable of being executed on a machine-readable medium.

The computer executable code may be created using a structuredprogramming language such as C, an object oriented programming languagesuch as C++, or any other high-level or low-level programming language(including assembly languages, hardware description languages, anddatabase programming languages and technologies) that may be stored,compiled or interpreted to run on one of the above devices, as well asheterogeneous combinations of processors, processor architectures, orcombinations of different hardware and software, or any other machinecapable of executing program instructions.

Thus, in one aspect, methods described above and combinations thereofmay be embodied in computer executable code that, when executing on oneor more computing devices, performs the steps thereof. In anotheraspect, the methods may be embodied in systems that perform the stepsthereof, and may be distributed across devices in a number of ways, orall of the functionality may be integrated into a dedicated, standalonedevice or other hardware. In another aspect, the means for performingthe steps associated with the processes described above may include anyof the hardware and/or software described above. All such permutationsand combinations are intended to fall within the scope of the presentdisclosure.

While the disclosure has been disclosed in connection with the preferredembodiments shown and described in detail, various modifications andimprovements thereon will become readily apparent to those skilled inthe art. Accordingly, the spirit and scope of the present disclosure isnot to be limited by the foregoing examples, but is to be understood inthe broadest sense allowable by law.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosure (especially in the context of thefollowing claims) is to be construed to cover both the singular and theplural, unless otherwise indicated herein or clearly contradicted bycontext. The terms “comprising,” “haa sender-controlled contact mediacontent item,” “including,” and “containing” are to be construed asopen-ended terms (i.e., meaning “including, but not limited to,”) unlessotherwise noted. Recitation of ranges of values herein are merelyintended to serve as a shorthand method of referring individually toeach separate value falling within the range, unless otherwise indicatedherein, and each separate value is incorporated into the specificationas if it were individually recited herein. All methods described hereincan be performed in any suitable order unless otherwise indicated hereinor otherwise clearly contradicted by context. The use of any and allexamples, or exemplary language (e.g., “such as”) provided herein, isintended merely to better illuminate the disclosure and does not pose alimitation on the scope of the disclosure unless otherwise claimed. Nolanguage in the specification should be construed as indicating anynon-claimed element as essential to the practice of the disclosure.

While the foregoing written description enables one of ordinary skill tomake and use what is considered presently to be the best mode thereof,those of ordinary skill will understand and appreciate the existence ofvariations, combinations, and equivalents of the specific embodiment,method, and examples herein. The disclosure should therefore not belimited by the above described embodiment, method, and examples, but byall embodiments and methods within the scope and spirit of thedisclosure.

All documents referenced herein are hereby incorporated by reference.

1. A method comprising: accessing a data set comprising a LIDAR acquiredpoint cloud comprising a plurality of points each of which areattributed with at least a geospatial coordinate; sub-sampling at leasta portion of the plurality of points to derive a representative sampleof the plurality of points; and displaying the representative sample ofthe plurality of points.
 2. The method of claim 1 wherein the LIDARacquired point cloud is acquired by a portable simultaneous location andmapping (SLAM) system.
 3. The method of claim 2, wherein displaying therepresentative sample occurs upon an interface display of the portableSLAM system.
 4. The method of claim 2, wherein displaying therepresentative sample occurs in real time during the acquisition of theLIDAR acquired point cloud.
 5. The method of claim 1 whereinsub-sampling at least a portion of the plurality of points comprisesdividing a volume represented by the point cloud into sub-volumes andassigning a value to each of the sub-volumes.
 6. The method of claim 5,wherein the sub-volumes are of substantially equal size.
 7. The methodof claim 5, wherein the assigned value of each sub-volume is indicativeof whether or not any of the plurality of points are located within thesub-volume.
 8. The method of claim 1, wherein each of the plurality ofpoints is displayed with an intensity corresponding to an intensity of areflection of infrared (IR) light from the point.
 9. The method of claim1, wherein each of the plurality of points is displayed with a colorcorresponding to an intensity of a reflection of infrared (IR) lightfrom the point.
 10. The method of claim 1, wherein each of the pluralityof points is displayed with a color corresponding to a parameter of theacquired data selected from the group consisting of an intensityparameter, a density parameter, a time parameter and a geospatiallocation parameter.
 11. A method comprising: acquiring a LIDAR pointcloud comprising a plurality of points each of which are attributed withat least a geospatial coordinate and a segment; assigning a confidencelevel to each segment indicative of a computed accuracy of the pluralityof points attributed with an identical segment; and displaying theassigned confidence levels to a user.
 12. The method of claim 11,wherein each confidence level is assigned based, at least in part, uponat least one of a point density of the point cloud, an orthogonality ofthe plurality of points, a geometry of an environment in which the pointcloud is acquired and a state of transition between separate spaces. 13.The method of claim 11 wherein the displaying comprises displaying theassigned confidence levels to the user utilizing color to indicate anassigned confidence level.
 14. The method of claim 13 wherein thedisplaying is performed on a display forming a part of a handheld SLAMdevice.
 15. The method of claim 11, wherein displaying the assignedconfidence levels to a user occurs in one of real-time or nearreal-time.
 16. A method comprising: acquiring a LIDAR point cloud with aSLAM system comprising a plurality of points each of which areattributed with at least a geospatial coordinate and a timestamp;displaying at least a portion of the plurality of points; receiving anindication of a specified time to which to rewind the acquisition of thepoint cloud; and tagging a portion of the plurality of points eachattributed with a timestamp after the specified time.
 17. A method ofclaim 16, further comprising erasing the tagged portion of points havinga timestamp after the specified time.
 18. The method of claim 16 furthercomprising: receiving an indication from a user that the SLAM system isnear at least one point having a geospatial coordinate corresponding tothe specified time; and resuming acquisition of the point cloud.
 19. Themethod of claim 16, wherein tagging comprises assigning the portion ofthe plurality of points as low confidence.
 20. The method of claim 16,further comprising removing the tagged portion of the plurality ofpoints after replacement points with an acceptable level of confidenceare acquired.
 21. The method of claim 16, wherein receiving anindication of a specified time comprises receiving a user request thatreferences the specified time.
 22. The method of claim 16, wherein thespecified time comprises a time associated with change in point clouddensity below a predetermined threshold.
 23. A method comprising:acquiring a LIDAR point cloud with a SLAM system comprising a pluralityof points each of which are attributed with at least a geospatialcoordinate and a timestamp; displaying at least a portion of theplurality of points; and displaying an indication to a user of a portionof the point cloud exhibiting a point density below a predeterminedthreshold.
 24. The method of claim 23, further comprising displaying anindication to the user of an unscanned area.
 25. The method of claim 23,further comprising displaying an indication to the user of a geospatialcoordinate to resume scanning.
 26. The method of claim 23, whereindisplaying an indication to a user of a portion of the point cloudexhibiting point density below a predetermined threshold comprisesdisplaying a target location for resuming scanning. 27-98. (canceled)